Writing Challenge
There’s this thing I found out about on Twitter that people call “NaBloWriMo”. It actually is a derived version of “NaNoWriMo”, which stands for National Novel Writing Month. Shortly, NaNoWriMo is a challenge where people have to write daily for one month, and in the end have a 50.000 words fictional novel. I didn’t know this exists, but I found of its other version, “NaBloWriMo” (ok, I’ve got to admit, I think this name sounds silly) from Maxim Cramer.
The rules I’ll follow during this challenge are:
- write every day
- publish at least one article per week
One article per week isn’t very much, but compared to my usual writing frequency, it’s a lot. And in the end, the goal of this is to create a habit for writing, not just to add 4 more articles to my blog. Because, as Ash Furrow says, sharing your knowledge makes you a better developer in the end.
Here’s to hoping I can finish the challenge🍷!
One week with the Apple Watch
When we got the Apple Watch delivered at Nodes, I was very happy and I was hoping that I would get to use it for a while, to see how it is and what it can do. I got to try it for about one week, and my first impression wasn’t very flattering for the company in Cupertino.
Most of the features that are advertised so hard by Apple didn’t really impress me. Yes, I could get all the notifications on my wrist too, not only on the phone. The important question is if I really want that. I’m not sure I want to feel a tap on my wrist every time a work colleague assigns me a Trello ticket, or when another recruiter wants to connect with me on LinkedIn. And yes, I know I can disable some or all of the notifications, but if I do that, what am I left with? An overpriced watch that doesn’t really look that good and that needs to be charged daily. However, towards the end of my week wearing the Apple Watch, I also found some nice features that I really appreciated.
When at home, I usually leave my phone in a room and don’t carry it with me around the house or in the yard. This means that I can’t hear it when it rings. However, with the Apple Watch, this problem is solved, because the watch vibrates when I get a call. This is probably the feature that I appreciated the most.
Another thing I really liked about the watch was the glance in which I could ping the iPhone. It sometimes (more often than I’d like to) happens to me to forget where I left my iPhone. One way to find it would be to ask someone to give me a call, but if the phone is on silent mode, this doesn’t help. I could also log in to iCloud and use Find my iPhone to make it ring. But that’s a bit more hassle than I’d like to. Using the Apple Watch, I can ping my iPhone in just 2 taps.
Another very cool thing is the way it vibrates. The taptic engine gives a much more human touch to it, instead of the artificial vibration we are used to. This somehow reminds me of the power LED on the MacBook Pros, that instead of flashing intermitently and mecanical, at regular intervals, it mimics the breathing frequency of a human being. It’s a nice touch which I really appreciated. As a downside, after not wearing the watch anymore, I thought I felt a couple of ghost taps on my wrist.
My conclusion for the Apple Watch is that it’s a decent device, with some features that I find as nice to have, some that I don’t need and one that I absolutely loved. The downsides are the huge price, the fact that I’m not fond of how it looks and that in order to wear one, I have to give up my current watch, which has sentimental value to me, and it’s not something I’m prepared to let go easily. I’m definitely not going to get an Apple Watch soon. But who knows what future models will bring?
The epicenter of improvement
I’ve been paying more attention to WWDCs only recently. Probably, WWDC 2014 was people’s favourite, because of the huge and revolutionary changes it brought. However, for me, WWDC 2015 is far better than the previous one, because it seems that we got what I always wanted from a platform and programming language that I use full time in my work: stability and improvements. Evolution and not revolution. I finally think that the Swift 2.0 that will come out of beta will be ready for production.
The WWDC main keynote is becoming more and more an event for journalists and press, and less for the developers. Platforms State of the Union is actually much much more important for a developer. If you’re an iOS developer and you’re too busy to watch more than one video from the WWDC, that should definitely be Platforms State of the Union.
It looks like Apple is changing, it’s becoming more open, more diverse. In the keynote and Platforms State of the Union, as well as in the other sessions, we saw more than only adult white males presenting. This is a great move by Apple, it shows that they want to change the current situation in the IT industry, and it will probably inspire more and more diverse people to join this industry. Another move, which I personally really appreciate, is that the recorded sessions are not screencasts anymore, and that they actually put a face on the persons behind the technologies we use every day. I hope this move will make people more ambitious, make them want to join Apple and/or contribute to the tools and technologies that allow us to do what we love to do.
All in all, the WWDC brought us many improvements, out of which I’d like to highlight the ones that excited me the most.
Swift 2.0. A lot of improvements here, and it looks like soon I will have no more reasons to prefere Objective-C over Swift.
Objective-C generics. Something that I missed when I moved from Java to Objective-C, which we saw in Swift and which is now also available in Objective-C. You will only get a compiler warning if you don’t respect the collection’s type, but that’s good enough for me.
Multitasking for iPad. iPad multitasking fuels the rumours of a 12 inch iPad Pro. But what I like most about the iPad multitasking is the brilliant way in which it was implemented. Size classes become now a huge deal, and using them makes supporting multitasking super easy.
UIStackView. We now have a UIStackView, which as far as I can tell is great if you don’t want to use a UICollectionView for a simple situation.
Address sanitizer in Xcode 7. I saw the session that showed Address sanitizer, and it loks great. Finally, it looks like we have a better way to debug that annoying
EXC_BAD_ACCESS.UI testing in Xcode 7. For someone that doesn’t do much testing, I’m very impressed by the session showing how UI testing in Xcode works. It is possible to create UI tests, and also to record UI tests. I’m looking forward to giving it a try.
There were also other announcements that made me happy, such as improvements in storyboards, storyboard referencing and others as well.
Also, we saw a change in the Apple Developer Program membership. There’s no need to have a developer account to run your app on your own device. Also, the mac developer program and iOS developer program have now merged. It is possible to register 100 devices of each type, not 100 in total (100 iPads, 100 iPhones, etc). And also, the Apple TV category appears now in the devices list, which raises my hope for a new Apple TV (maybe, an TV), with an SDK and lots of content. We’ll see.
We have exciting times ahead of us. Let’s take advantage of everything we have and build great stuff.
Self sizing UITableViewCells
Among all the new features brought by iOS 8, and the launching of Swift, there was also a minor thing that not many people talked about. iOS 8 brought auto-sizing table cells.
This is probably one of the iOS 8 features I was most excited about. Probably everyone who developed an iOS app has used a UITableView. It’s one of the most basic and most used components. And we all know the pain of computing the tableView:heightForRowAtIndexPath: for custom cells with different heights depending, for example, on the data you get from an API. And then, setting frames by hand in the layoutSubviews in the UITableViewCell. It probably never was a good approach, but I’ve seen code like that and I’ve written code like that (not proud of it).
Then, Auto Layout came along, and we had a way to get rid of all the frame computing in the layoutSubivews in the cell. But we still had to compute the height of the cell in the view controller, and the only way I found to make Auto Layout work well with dynamically sized cells was to actually instantiate a table cell in heightForRowAtIndexPath and use it just for sizing the cell. Not very nice.
iOS 8 is the one that finally brings us a good solution: self-sizing cells. In other words, if you add the right Auto Layout constraints in your cells, you won’t have to tell the tableView the height of the cells, but he will know to get it himself.
Before jumping with joy, please note that this is only possible in iOS 8. So if you have to support iOS 7 as well, this is not a good solution for you.
I created a small project, to test this new feature. We have a UITableView with custom cells. The data for the it will be fetched as a JSON from here. I’m not going in details about fetching data from a URL or parsing a JSON to custom objet, these are pretty basic things and don’t make the object of this article.
The key to get auto-resizing cells is to set the constraints inside the cell in the right way.
TitleLabel is pinned to top, left, right and has the bottom pinned to the nearest neightbour (the imageView). The UIImageView is pinned to the left, right, has the height set and its botton is pinned to the nearest neighbour (the DetailLabel). The DetailLabel is pinned to left, right and the bottom is pinned to the bottom of the cell.
That’s it. This is all. You don’t have to do anything else. Well, of course, set you tableView delegate and datasource, return the cell for each row, the nubmer of rows and that’s it. No heightForRowAtIndexPath. And make sure you don’t set any Row Height for the table view in the storyboard. Leave it the default (which is 44). Setting it to anything else seems to make all the cells that size.
You can find the demo project on my GitHub. Don’t try running it on iOS 7, because it will crash (conflicting constraints; it assumes the height is 44, but the inner constraints of the cell make its size to be much bigger; so it crashes).
I think the self sizing cells are a big step forward and I’m looking forward to have an iOS 8 - only app, so I can actually use them in production.
Why I didn't start playing around with Swift
So, as everybody probably knows, Apple launched Swift at WWDC, on June 2nd. Despite my initial perplexity (wasn’t expecting that) and my further excitement, I still haven’t written a line of Swift code, even though it’s been almost 2 months since it was launched.
Yes, I won’t be able to say that I was coding Swift since day 1. But I don’t really care about that. I also haven’t programmed in Objective C since the first day it was launched, and that never stopped me.
A lot of people were excited about closures. They’re nice, true. I’ve worked in functional programming languages in University, so I kind of know what they are and how to deal with them. And I didn’t quite miss them in Objective C so far.
Many guys want to try it as soon as possible, so they have a word to say in the “upbringing” and the future of this language. I totally understand their point. But it’s not the case for me: I trust other people will do a very good job at finding problems, opening radars, modelling the language and making sure it’s going in the right direction.
But after all, the truth is that Swift is still experimental. A language that is constantly changing every two weeks, with every new beta launched, is definitely not a language I would like to write production code in. Yes, it’s nice to experiment with new technologies, I’m a big fan of that. But it’s not the right time now to do that with Swift. At least, not for me. But my vacation should start soon, so who knows :D ?
Singletons
I like Singletons. This was the first design pattern I learned while studying OOP and it’s by far the one I’m most comfortable with at this point.
In (almost) all my projects that need networking, I created a singleton NetworkManager, which handles all the network communication done throughout the app. I think that this is a very good example of a situation where a Singleton is useful.
How I write my singletons
If there’s nothing fancy about the classes I want to be singletons, I simply include the following code in the .pch file:
#ifndef SHARED_SINGLETON
#define SHARED_SINGLETON(class) \
+ (id)sharedInstance { \
static dispatch_once_t pred = 0; \
__strong static id _shared##class = nil; \
dispatch_once(&pred, ^{ \
_shared##class = [[self alloc] init]; \
}); \
return _shared##class; \
}
#endif
Then, in the header file of the class I want to make a singleton, I add the function
+ (id)sharedInstance;
And in the associated .m,
SHARED_SINGLETON(Open311);
is the implementation of the sharedInstance method. From now on, every time I need this object, I call it with [ClassName sharedObject].
Of course, if you need to do other things when fetching that Singleton, you need to add the method in your .m file and do it there.
Good or bad
This is quite subjective, and depends really on how you use this pattern. It can be both good and bad. And it depends on how you write your singletons. ALWAYS use dispatch_once to instantiate your shared instance. The older method of @synchronized is also acceptable, although arguably slower. This way, you are sure that your singleton is thread-safe.
Some refuse to use Singletons because they are just glorified globals. But where do you put that data instead, if you need it all through the app? AppDelegate? But.. surprise.. the app delegate is actually a Singleton.
Conclusion
You can like or you can hate the Singleton pattern. Actually, as long as you know what you’re doing, I don’t see any point in avoiding singletons.
My Middleman powered blog, hosted on GitHub Pages
I would say I have quite some experience with Wordpress. I’ve first used it in 2007, and I’ve continued to use Wordpress as a CMS for almost all the websites I needed to create. I did this because it was an easy solution for what we needed.
Why Middleman
But when I decided to create my own website, Wordpress wasn’t really my first option. I’m not really sure why I chose Middleman, but now that I’m using it, I know exactly why I like it.
Middleman builds static websites. There’s no database required, all you need to do is write the articles using markdown, and they will be built into static html webpages. For me, the biggest advantage of this is that I can host it on GitHub Pages. I couldn’t have installed Wordpress, for example, on a GitHub Pages website, because Wordpress needs a database on the server. Another very nice feature is that each article is basically a text file, which can be easily kept on git. Also, because it’s written in markdown, it’s very easy to add code in the articles, and it looks very good. And finally, writing your articles in a simple text editor (or maybe even in vim) gives you that geekish feel, which can’t be accomplished by using Wordpress, Joomla or other WYSIWYG engines.
On the other hand, middleman is not as easy to use as Wordpress. For technical guys it’s ok, but I wouldn’t imagine, for example, my dentist using Middleman to maintain a blog. Wordpress is much more accessible.
How I did it
Middleman comes as a Ruby gem. You have to open a terminal and then sudo gem install middleman-blog. Now you have the blogging extension of middleman installed on your computer. To start a website, all you have to do is middleman init MYBLOG --template=blog. This generates the following:
MYBLOG
- .gitignore
- config.rb
- Gemfile
- Gemfile.lock
- source
- 2012-01-01-example-article.html.markdown
- calendar.html.erb
- feed.xml.builder
- images
- index.html.erb
- javascripts
- layout.erb
- stylesheets
- tag.html.erb
Of course you can replace MYBLOG with a name of your choice.
Erb is the default templating language of Middleman. Haml, Sass, Scss and others are also supported, but when I started this project, I didn’t find any good reason to switch from the default. I still don’t.
A very important file is the config.rb. This is where all the configurations of the site are. Middleman has a very god documentation, and it’s easy to understand how it works. But just for inspiration, my sources are public on GitHub.
To add an article, you can go to Terminal and write
middleman article "Your Title"
A new file is created in the source folder, corresponding to this article. The articles are written in markdown language, and all they contains are the text, maybe images, links and metainfo such as date and tags. All the styling information is somewhere else, and we will talk about this in a short while. The file created in the source folder has only the title, date and an empty list of tags for the article. Write something as the content of the article.
At this moment, you can run bundle exec middleman server and go to the link shown in Terminal (http://localhost:4567). You will see a very plain html blog, with your first article.
To improve the appearance of the website, you will need to use your HTML and CSS knowledge and create or adapt a template. The file layout.erb is the one containing the layout of the website. Here you can add the code for the header, footer, maybe a sidebar, etc. The layour.erb is kind of a frame, which appears on all the pages of your blog. <%= yield %> is the part which is actually framed using this layout. The index.html.erb file contains the styling of the content which is yielded in the layout.erb file. For example, here you can write and style the title, tags, date of an article. My advice is to get a free HTML template you like and adjust it to fit you needs. Very important, in my opinion, is to choose a responsive layout, one that looks good on all resolutions, including phone or tablet. I learnt this the hard way, and in the beginnig of 2014 I will probably change the layout of my site.
Publishing your blog on GitHub Pages
GitHub offers GitHub Pages, mainly for creating a small site about each of your projects. But this can be used also to host your personal developer website :). I chose to have this blog as a separate repo than the rest of the site. The nice thing is that Middleman is perfectly integrated with GitHub pages, all thanks to the middleman-gh-pages gem. I included it in the Gemfile
gem "middleman-gh-pages"
and required it in a Rakefile:
require 'middleman-gh-pages'
Then you have to bundle install again, and now you are ready to push to your gh-pages branch, in order to publish your built website. And middleman-gh-pages does this for you, with
bundle exec rake publish
The contents of your gh-pages branch will then be published at username.github.io/repo_name. The master branch will contain the source files, and the gh-pages branch will contain the built website. Running the publish builds your website and pushes it to the gh-pages.
That’s about it. There are some references I found very useful below, and the sources for this blog. For discussions about this articles, send me a tweet.
Resources:
- Middleman documentation: getting started
- Middleman templating
- 12devs - building static websites with Middleman
- Joey Aghion - Building a blog with Middleman and GitHub Pages
- Joel Hans - Building a middleman blog
- Repo for my blog - have a look at both the master and the gh-pages branch