Learn All The Things

My new Mac setup

Simon Goudie — Sat, 16 Sep 20113 00:00:00 EST

I recently updated my entry-level mid-2011 13" MacBook Pro to a nice new mid-2013 13" MacBook Air. I went with the 256Gb SSD version and bumped the RAM up to 8Gb and, so far, it's been a great machine. As with all new setups though, this needed a bit of customising as I setttled in and I thought I'd make some notes on what I put on, mainly for my own reference.

So, these are the details of the second setup of the Air - I say second, as the first thing I did was to try to setup the same triple boot as I had on the Pro (OSX, Windows 7 and Ubuntu). Bootcamp makes installing Windows easy, but there are still huge problems in completing the Ubuntu install on the new Air hardware and I ended up having to to a full disk erase and Mountain Lion recover by the end of the first day! I'll have to be content with just OSX and Windows for now.

At any rate, here's the software that made up the essentials for the new OSX install:

Chrome: still the best browser for me, although I worry about the RAM usage over time
Git: makes it easier to download and manage many other things, including...
Dotfiles: keeping my dotfiles on GitHub makes it easy to move settings between machines. These aren't kept in the best shape, but there's enough in there to get me setup and comfortable on a new Mac. PC or Linux box. These files include settings, plugins and themes for zsh, vim and other utilities
Vim: my editor of choice, so I use MacVim on OSX and plain old Vim on the command line
XCode: command lines tools and homebrew: the basics of the toolkit
Dropbox: keeps a lot of my files, including projects, photos, settings and so on, in sync between machines
SuperDuper: for backing up to an external disk that's also partioned with a Time Machine instance
Launchbar: my preferred launcher app, keeping my fingers on the keyboard
Caffeine: keeps the screen on, useful when keeping an eye on the progress of all the downloads and installations going on
Growl: I don't really use it to its potential, but it goes on to manage notifications
PopClip: I'd be lost without this one, I cycle through extensions fairly often, but it's worth it for the clipboard actions alone
1Password: again, I don't use it to potential, but it is the way I manage product keys and some passwords
Sparrow: I worry for its future, but I still love it for email
Moom: after switching from Windows a couple of years ago, I still have no idea what the green button does. Now it does what I want
VLC: the omni-media player
Office: unfortunately still necessary these days

Some nice tweaks that follow soon after:

Bartender: tidy up an unruly menubar
F.lux: make it all much easier on the eyes
TotalFinder: I quite like what this adds to Finder, although it will be interesting to see what get duplicated in Mavericks
TotalTerminal: I've tried using other termainal emulators, but I still like using TotalTerminal's visor mode, mapped to Control-~
iTunes: logging in and setting up iTunes match, although Rdio gets most of my music listening currently
Plus a nice background and at least two Spaces - one on the left for Sparrow/Twitter and one on the right for working. The dock gets sent to the bottom left of screen and autohides for maximum screen real estate

And then the rest of the apps that I use every so often:

Evernote: still trying to work out where Evernote fits in my workflow, but I've ended up with a couple of years of Premium on my account all the same
Transmission: for downloading those big... distros
Steam: mainly for Civilization V and FTL
Anvil: nice for local web experiments
VirtualBox: usually for messing around with creating Linux servers
App Cleaner: I think this is better for removing apps from OSX, but still not sure what best practice is
Dash: a great way to check up on documentation
Plus: Skype, Day One, iPhoto, Cheatsheet, Byword, Coda 2, Marked, Pages, Reeder, Twitter, Kindle

That's actually a pretty long list, it really doesn't feel like that when everything is set up and running! Dropbox and hosting some dotfiles on Github really make transferring settings a breeze and it doesn't take long from a fresh install to feel comfortable again.

Monitoring a Raspberry Pi on Status Board

Simon Goudie — Fri, 12 Apr 2013 00:00:00 EST

Panic's latest iPad app, Status Board, offers a really attractive dashboard to monitor key statistics, email, social media and other goings on. I really don't have that much use for it, but I downloaded it to play with anyway.

One thing that I thought I could monitor was the CPU load on my Raspberry Pi server that I keep running from home. It's not a production server, just a sandbox to play in, but I thought it would be the kind of thing that Status Board should be used for. Seeing that Status Board works well with StatHat, and that StatHat offer a feature-reduced free tier, I thought I would see if I could tie all of these together to get something happening.

Here's what I got to work. I'm sure there are better ways to do this and I'm sure something like Nagios would be a much better alternative, but this was what I chose to play with.

Getting stats from the Raspberry Pi

My Pi runs Arch and is a very barebones setup. It's easy to get the current CPU load average via the /proc/loadavg file. This file gives the load average for the last one, five and 15 minute window, as well as some process info. I wanted to log the one-minute average, so only needed the first four characters of this file to be dumped out. Starting a short script, the line

loadavg=`head -c 4 /proc/loadavg`

was enough to grab the current one-minute average and place it in a variable called 'loadavg'.

Sending the stats to StatHat

StatHat make it really easy to send them data to log. There are a whole stack of ways to do this programatically, but I opted to use the cURL method so I could add it to the same script. Once you have a StatHat account ready, sending the data is as easy as adding a single line to finish the script:

curl -d "stat=Pi Load&email=YOUR@EMAIL.COM&value=$loadavg" http://api.stathat.com/ez

This takes the figure that we pulled from /proc/loadavg and send it to StatHat to add to the 'Pi Load' log.

Doing this more than once

Having the commands to pull the data and send it are great and putting them in a script makes it even easier, but it's no good unless this is being done regularly and automatically. A cron job to do this every five minutes takes care of this task. I'm certainly not a cron expert, but here's what works for me. Running crontab -e will open your editor to enter the cron tasks. The syntax to do this is better explained at this site than what I could do, but, effectively, this line will run your script every five minutes and scrap any output (otherwise cron may email it to you, a great way to fill your inbox):

*/5 * * * * ~/path/to/your/script.sh > /dev/null 2>&1

The script I run is literally just the two lines that I mentioned above, here's the whole thing:

#! /bin/zsh
loadavg=`head -c 4 /proc/loadavg`
curl -d "stat=Pi Load&email=YOUR@EMAIL.COM&value=$loadavg" http://api.stathat.com/ez

Displaying the log on Status Board

StatHat is one of the two services that are already integrating with Status Board. This makes it super easy to drop the log into Status Board and have it come out as a nice graph. Just visit the log on the StatHat site, choose the timeframe you want to plot and look for the 'Status Board Graph URL' button at the bottom of the page. This can email the URL to your iPad. Once there, copy the URL, open Status Board and add a new graph, pasting in the URL you received.

That's about it

With the graph added, you're all done - the cron job will pull the load data every five minutes and send it to StatHat, where it will be pulled from Status Board to display. It may look something like this:

I quite like StatHat - they offer a really good site and adding data is dead easy. Unfortunately, their one price point of US$99/month means that it won't be worth me signing up to unlock all the features of the site and will remain on their free plan, limited to ten stats (probably enough) with no automatic alerts or small-interval tracking (a bit disappointing). Hopefully, more services will be integrating with Status Board soon and the options will open up a bit.

Publishing with Jekyll

Simon Goudie — Sat, 08 Dec 2012 00:00:00 EST

After using WordPress for years for both blogs and content sites, I was looking for a new way to host my own blog, as well as an opportunity to experiment a bit more with CSS and hosting options. A number of Ruby tutorials use writing a CMS as their end product, but I wasn't too keen on doing that and instead came across Jekyll as a way to create a static site from a set of markdown files and layout templates. So after spending a while learning how the different pieces of the site come together, how the Liquid tags work and the best way to deploy the site from the various local and remote systems I've set up, I've finally switched this site over from a standard WordPress install to a deployed Jekyll static site.

There's still a fair bit left to implement - a lot of the styling needs to be done, RSS needs to be fixed up, more pages need to be added and there's probably a lot of stuff that should/shouldn't be in the 'head' tag. However, the basic site seems to work fine and the deploy scripts seem to work from each place I might want to write from. The full site, with the exception of a drafts folder, is kept on GitHub. I'm not using GitHub Pages to host it at this stage, but I have set up a page that I might use in future. Instead, the site uses Glynn to push it to the shared host that it lives on, or rsync to push to a test server on a VPS.

I've found Jekyll to be a great way to experiment with putting together a site, with a good balance between control over layout/configuration and automated 'magic' to make the site all come together and be ready to upload. I look forward to doing more work with it and will look at using it for other projects in future, too.

Rails: Trusting the magic

Simon Goudie — Thu, 23 Aug 2012 00:00:00 EST

I'm working my way through a couple of Ruby on Rails tutorials at the moment, looking at why this framework has gotten so much interest. In particular, Michael Hartl's tutorial has been excellent. So far, things are going well and I have a nice little app coming together. However, the thing that gets me with such frameworks and helpers is the level of abstraction from what you are writing at any given time.

I don't know if it's just the way I work or not, but I'm most of the way through the tutorial series and I'm still struggling with the amount of 'magic' that Rails is doing on my behalf. While I can see the advantage of simply installing a few dozen gems and not writing a full framework from scratch, I can't help but be a little puzzled when the notion of database access or password hashing is hand-waved away by the framework. Writing tests, while a great way to develop, is likewise confusing and I'm still finding that the attempt to use a native-sounding syntax is more confusing than helpful. Differentiation between bracketing types {([||])} is another puzzling aspect that I'm having trouble finding consistency with, something that I'm sure is to do with the way that the lower-level Ruby code is abstracted away.

So yes, I can see the benefits in using such a framework and I can see the time saved in bootstrapping an app, but there's only so much opacity that I feel comfortable with in a framework and, at this very early stage, Rails seems to be way over the limit. Hopefully, continued practice will make me feel more at home and I will be able to relax into it a bit more, trusting the magic to hold up in the end.

Adding email data export to iOS apps

Simon Goudie — Sun, 29 Jul 2012 00:00:00 EST

Very happy with how easy it is to add email capabilities to an iOS app. Following the example given at Mobile Tuts+, it was pretty simple to add an export function to my test app that now means users can have a csv file of their data emailed to them from within the app itself quickly and easily.

The process to prepare the csv file is still a bit of a mess and the whole process needs a bit of a tidy, but overall, it was a painless process.

If you're interested in following along, the Tracking app is being maintained on my GitHub page.

WWDC videos

Simon Goudie — Tue, 03 Jul 2012 00:00:00 EST

Nothing much to post for now, as I haven't had much time to keep working on my projects. However, what I will say is that the WWDC session videos are great watching and are packed full of great information and explanations. If you have a developer account, it would be well worth the time to check out a few that relate to the systems you use. They can be found at http://developer.apple.com/ videos/wwdc/2012/ and are also available through iTunes U.

Sharing port 443 between SSL and SSH using SSLH

Simon Goudie — Sun, 03 Jun 2012 00:00:00 EST

The port that SSH runs on, port 22, is firewalled on a lot of networks. Conversely, ports 80 and 443 are almost always open for HTTP and HTTPS traffic, respectively. This presents an opportunity to SSH via port 443 rather than 22. However, only one service can listen on a port at once, so you would usually have to choose to run one or the other. There is another service though, SSLH, that can run as a multiplexer and listen on 443 instead of SSL or SSH. When SSLH receives traffic, it can decide if it should go to SSL or SSH and redirect accordingly, effectively meaning that both SSL and SSH can run on the same port.

Setting up SSLH was more of a learning experience than I expected, so I'm making some notes here that might help someone else, and myself in future.

Installing on my CentOS VPS (affiliate link!) was simple enough. Yum found it and installed it using a simple:

yum install sslh

Looking at the readme file gives a quick copy instruction for CentOS to set up the config file:

cp scripts/etc.rc.d.init.d.sslh /etc/rc.d/init.d/sslh

That's the easy bit - SSLH is now ready to run, but there's a bit of configuration to do first. The goal is to reach the following situation:

Connection is made to port 443
SSLH receives it and recognises traffic type
If SSH, the traffic is passed to localhost:22, where SSH is listening on all port 22 connections
If SSL, the traffic is passed to localhost:443, where Apache is listening only on localhost:443 for secure connections

The SSLH configuration file (at /etc/init.d/sslh) looks pretty straightforward, with only one line to change:

OPTIONS="--user nobody --pidfile $PIDFILE -p 0.0.0.0:443 --ssl localhost:443 --ssh localhost:22

Looking at this line, the intention is to set the user running the process as 'nobody'; allocate a process id; listen at 0.0.0.0:443, which is port 443 on all IP addresses; redirect SSL traffic to localhost:443; and redirect SSH traffic to localhost:22 (Note that this is NOT the configuration that worked for me, keep reading).

It's worth noting that there are other SSLH configuration files, such as /etc/sysconfig/sslh. I'm sure that these are there to make the settings easier, and indeed the readme references the one at /etc/default/sslh, but I just ended up getting confused and setting conflicting options. In the end, I just deleted the additional settings files and just used the main file at /etc/init.d/sslh.

SSH doesn't need to be changed, as by default it listens to port 22 on all IPs, including localhost. As a side note, localhost should be equivalent to 127.0.0.1 and to the machine name.

SSL does need to be changed, as by default, it will be listening to port 443 on all IPs. This will clash with SSLH, which needs sole access to port 443. Instead, according to our goals above, we need SSL to listen only on localhost:443. This is where I ran into trouble. Apache has one main config file at /etc/httpd/conf/httpd.conf where the main LISTEN directives are listed, however, neither Listen 443 nor Listen localhost:443 should go there. The secure site is handled as a virtual host, which has a spot at the bottom of the httpd.conf file. The virtual host section contains all the information about the SSL certificates (another post altogether) as well as the port to listen on. However, another gotcha is that the httpd.conf file includes other files, in the same way that source files use 'require' and 'include' or web files can pull in css or javascript files. In this case, the httpd.conf pulls in the file at /etc/httpd/conf.d/ssl.conf. It is in this file that the virtualhost settings should be listed. Getting these mixed up means that you're very like to get overlaps on ports when you restart Apache.

Making things more complex was that, no matter what I did, I couldn't resolve the clash caused by SSLH listening to port 443 on all IPs and SSL listening on localhost:443, which is obviously included in all IPs. I never worked this out, and instead changed SSL to listen on port 442 with the virtualhost section starting with:

<VirtualHost localhost:442>

This meant that the SSLH config file also needed to be updated to point SSL traffic to localhost:442 instead of localhost:443. Clash resolved, with the SSLH options line now reading:

OPTIONS="--user nobody --pidfile $PIDFILE -p 0.0.0.0:443 --ssl localhost:442 --ssh localhost:22

Restarting the HTTPD service, then the SSLH service and then using a web browser to check the https:// site, it looked like all was in order for the SSL setup. Unfortunately, SSH was still not working on port 443. When trying to connect, the client would initiate the connection, but receive no response from the server. Switching SSLH to the foreground verbose mode with the --v switch, it showed that it was intercepting the traffic, but the connection was being refused (suspiciously, the error included the letters ssl). No amount of port configuration changing on either the SSLH side or the SSH side was helping and I was ready to admit defeat. As one last test, I deleted the --ssl section from the SSLH options line to remove SSL from the equation. SSH then connected perfectly. I then added the --ssl section back in, but this time after the --ssh section. Restarted all services and both SSL and SSH ran beautifully via external connections on port 443! I can only assume that SSL was jumping in first and causing trouble by not passing the traffic to SSH. By reordering the options, SSH must get first shot at the traffic and must be better at deciding to take it or pass it on to SSL.

The final /etc/init.d/sslh options line used was:

OPTIONS="--user nobody --pidfile $PIDFILE -p 0.0.0.0:443 --ssh localhost:22 --ssl localhost:442

Obviously, this is not a perfect setup and I'm sure I've overlooked some basic points, especially about how to leave Apache listening to localhost:443 rather than switching to localhost:442. However, I'm happy to have SSLH working correctly and now have a much better understanding of how Apache is configured, how ports are configured and how Linux services work.

So, for future reference, my SSLH 1.13 setup checklist for CentOS 6.2 is as follows (assuming correct permissions level and not including TLS/SSL certificate setup):

install SSLH:
copy the CentOS config file across:
set Apache to listen for secure sites on localhost:442, using /etc/httpd/conf.d/ssl.conf:
set SSLH options line in /etc/init.d/sslh:
(re)start services, first:
and then:

Properties, variables and underscores

Simon Goudie — Mon, 21 May 2012 00:00:00 EST

This was something that confused me for quite a while. No doubt I'm still missing most of the detail involved, but I wanted to jot down here my current understanding of the way instance variables and properties are used in Objective-C code.

The puzzle starts with the header code that is in many tutorials and examples (please bear with my mockup):

@interface TheClassName : NSObject <NSCoding> {
    NSMutableArray * _foo;
    NSInteger _bar;
}

@property NSMutableArray * foo;
@property NSInteger bar;

and then continues at the start of the matching .m file:

#import "TheClassName.h"

@implementation TheClassName

@synthesize foo = _foo;
@synthesize bar = _bar;

In isolation, I understood the idea of declaring variables, as well as the idea of synthesizing properties. However, looking at the above combination, why declare variables, then created them as properties, synthesize them, and then complicate things by using names with underscores? Seems like trebling the work and then obfuscating it!

Thankfully, we have StackOverflow, which has addressed this matter a number of times. The question that helped me the most, though, was this one: 'Why do you use an underscore for an instance variable, but not its corresponding property?'

Turns out, the underscore works to differentiate the raw instance variable (_foo), which should only be referenced from inside the instance (and even then it's apparently not a good idea, for reasons to do with reference counting I think), with the property (foo) and its associated methods (foo and setFoo), which can be safely used and called from elsewhere. Therefore, when setting foo, you have the option of the unsafe

_foo = x;

or the safer

[self setFoo:x];

or, from outside the class, the safe

[TheClassName setFoo:x];

It's an added layer of abstraction from working directly with the variable, but if it makes it safer to rely on Xcode's memory management, then I'm ok with that. Looking back over the code I've been writing, I realised that I had a fantastic combination of property usage and variable usage, with no logic behind any of it. A short time later, all of that was much more consistent and made full use of the properties, with no remaining references to the raw variables. Everything compiled and ran fine, so I feel much more confident about the way I'm creating and using these properties.

The code is still on GitHub and any comments would be appreciated. Likewise, I'm sure the above story is wildly inaccurate in parts, so let me know!

VPS - an education in servers

Simon Goudie — Tue, 24 Apr 2012 00:00:00 EST

You can get Virtual Private Servers for $15/year. A YEAR! Sure, they've got less RAM than my couch, but $15 is a pretty small price to pay for a new playground. I signed up for SpotVPS' offering (affiliate link!), which is a VPS with 128MB RAM (256MB burstable), 10GB storage and 500GB of bandwidth.

It's dead easy to set up, you just specify which OS you want loaded on your virtual server, then away you go. There's next to nothing by way of support, so it is a bit daunting to be left with the barebones of a server and not much else. I initially SSHed in and had a look around, realising that I should get a better feel for the OS. I initially opted for an Ubuntu install, as I had had a bit of practice on the desktop; however, this seemed to use too much memory, so I switched for CentOS. I don't know a whole lot about CentOS, but it turns out to be an offshoot of Red Hat Enterprise that is very stable, but not necessarily on the latest versions. The book 'The Definitive Guide to CentOS' is a pretty easy read and was really helpful in getting a handle on what was going on and before too long I had user accounts set up and some idea about using Yum to install packages.

After this orientation, I was able to install and setup:

Webmin, to make server management much easier
PHP, mySQL and configure the existing Apache install
proFTP
update DNS settings to route a spare domain name (Simon4)
and, finally, WordPress.

Having WordPress up and running was the first achievement I was aiming for, as a way to prove that I could setup and configure a server with the necessary requirements. With WordPress running, a lot of other common web hosting tasks would be possible, so I'm pretty happy with hitting this target.

So, lessons learned from a bargain-basement VPS setup?

Firstly, 128MB of RAM is nothing! Even now, the server typically idles at around 180MB being used after a reset, frequently maxing out and throwing strange errors in the SSH session. Moving up to 512MB (1024MB burstable) is only $50/year, and I'll probably make this change if I continue to use the server.
Second, a VPS is a great test environment. If things go horribly wrong, then it is just a button press to restore the SOE or change to a new OS.
Third, Linux should not be feared. I don't have a great deal of experience with Linux systems, but there is plenty of documentation and Googling for answers is a a great way to get a feel for the system and the esoteric corners that you need to explore. If something isn't working, you just start at the bottom and work backwards to find what's broken!
Fourth, setting up a server is a great way to see just how transparent the structure of the web really is. You get to see every cog and play with every setting. You quickly realise, just like learning HTML, that the every web site is based on the same common technical elements.
Lastly, the command line is woefully underrated. Being able to administer whole servers from a CLI shows the real power of the interface. SSH out is blocked at work, but I had the exact same abilities with a Prompt session running on my iPhone over 3G. I really look forward to developing some more bash and scripting skills to exploit the command line.

All in all, I was pretty happy with what I was able to put together for $15 and half a weekend's worth of effort and research. I've now got my own platform to experiment with, break and repair with full control (as opposed to having to fill out tickets for a hosting company to action when changing MX records - also a project that was accomplished on the weekend).

Editing in Vim

Simon Goudie — Sun, 25 Mar 2012 00:00:00 EST

On the path to becoming a real geek, the command line is pretty key. I've never been scared of the DOS prompt in Windows, but haven't had much exposure to the terminal in OSX or Linus until recently. As part of coming to terms with working from the keyboard, I decided to tackle one of the seminal text editors - either emacs or vi.

I ended up choosing Vim as it seemed to fit my style of working a bit better, purely personal preference. Perhaps a lot of the decision had to do with already being used to the idea of using j/k to move p and down in other programs, like Reeder and the Google apps. So I picked Vim and got to work. I had the typical initial shock of modal editing, that is, one mode for entering text and another mode for everything else, but soon began to see the logic and the power in it. I worked through the built-in tutorial, then found a few more resources to work through online (I think that this article by Steve Losh made a lot of things click in to place).

Before long, I was somewhat competent. At least, I was no longer deleting paragraphs and not knowing why, and I also learned to work out where I was saving the files I was working on - although I did spray test files throughout the file system in learning this. I found a nice theme, Solarized, and worked out how to make Vim behave on the different operating systems. Importantly, I also discovered the power of the .vimrc file and set about putting together a set of options that further enhanced Vim, but without going overboard and copy/pasting dozens of other people's settings into one ugly file.

While I still don't need to use Vim for much coding (most of it is in Xcode), I try to use Vim for all my text notes and replaced Notepad with Vim as the default editor on my Windows machine. Vim's ubiquity means that I can run it on my MacBook, my Windows machines and also on the Ubuntu instances that I'm playing around with. I even put it on my iPhone and iPad, although the utility of this is still questionable! To keep everything in sync, I store my master .vimrc file in a Dropbox folder and then use the 'source' command from each machine's local .vimrc to import these settings. This means that there's only one .vimrc file to change and all the settings are kept up to date on all machines. Any OS-specific settings also get put in the local file, but there aren't very many of these. In case anyone is interested, I have added my settings files, including the master .vimrc, to my GitHub profile - these can be found at: https://github.com/simongoudie/dotfiles.

Table view

Simon Goudie — Wed, 21 Mar 2012 00:00:00 EST

So table views are a bit more trouble than I thought they'd be. As the second view in the tab bar, I want to display a table view with each item in a row. Tapping on a row should go to an item screen with more details and some actions. Currently, the items are added to a mutable array (probably to move to a database when I get around to learning how to implement one). The items are 'food' objects with a number of properties, the key one being the name which is in the property 'food'.

I initially thought that I could create an instance of a table object, pass it the array and tell the table how to arrange the array in rows and columns, as well as what to do when clicked. Not quite so easy. Turns out there's a whole heap of pieces that need to be implemented to get this working, not many of which are intuitive. First up is making sure the file knows that it's working on a table, so the .h file needs to include

@interface TrackingTableViewController : UITableViewController

After this, there's a set of functions that need to be implemented. I found these out through much Googling and trawling Apple documentation, but mostly ended up keeping the bare bones structure of the functions. The fuctions that were basically copypasta included:

- (id)initWithStyle:(UITableViewStyle)style
- (void)viewDidLoad
- (void)viewDidUnload
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView

The prototype functions I left commented out, most of which I believe are editing functions, included:

- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath *)indexPath
- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath
- (void)tableView:(UITableView *)tableView moveRowAtIndexPath:(NSIndexPath *)fromIndexPath toIndexPath:(NSIndexPath *)toIndexPath
- (BOOL)tableView:(UITableView *)tableView canMoveRowAtIndexPath:(NSIndexPath *)indexPath

The trickiest part (for now) was to work out how to get the data from the array to the cells. I eventually caught on to how the tableView:cellForRowAtIndexPath: was meant to work, in addition to the concept of recycling table cells. I'm still not completely au fait with this concept, but on the face of it, it looks like once a cell is scrolled off screen, it is then reused for the cell coming up on to the screen (rather than generating cells for every row, onscreen or off). With that in mind, the function turned out to look like:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    UITableViewCell *cell = [tableView 
                             dequeueReusableCellWithIdentifier:@"ReuseCell"];
    TrackingFood *food = [self.tableViewArray objectAtIndex:indexPath.row];
    cell.textLabel.text = food.food;
    cell.detailTextLabel.text = food.reminder;
    return cell;
}

Not to forget setting the number of rows required:

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
    return [self.tableViewArray count];
}

And there was a table! This was a long time coming in itself, but a problem quickly became apparent - once the table was generated and displayed once, adding new items to the array didn't show up in the table. Turns out that the table needed to be reloaded. How? Well, it seemed to be linked to the tableView reloadData function, but how to call it? On viewDidLoad was the first thought, but again, this only works on the first time the page is created, so no go there. So if viewDidLoad happens on the first visit, what happens when you move to that view after the first time? viewWillAppear, apparently. This seemed to do the trick:

- (void)viewWillAppear:(BOOL)animated
{
    //    [tableView reloadData];
    [self loadArray];
    [self.tableView reloadData];
}

So finally: - I had a table - It filled with the array data - It reloaded that data and updated the display each time it was shown

The next challenge? Creating a new view to display item details for an item selected in the table. More on that soon, but the main problem was how to pass the correct item and its data from the table view to the new item view, particularly when I have no idea what the table is called or how to address it!

The next project

Simon Goudie — Tue, 28 Feb 2012 00:00:00 EST

So the general idea of rebooting this blog is to track things that I'm learning and to keep myself honest by posting updates, questions, answers and interesting things that I find along the way. Given that the first entry was some Objective-C code, it should be no surprise that learning to program something functional is on the list of things to learn.

I guess that the best way to learn is to do, so the pet project to practise on at the moment will be a tracking app to keep track of things over time, the first use case will be to track what food the user eats and then how they feel later on. This is mainly because I often feel crap after eating and would like to find out what I shouldn't eat.

Continuing with the theme of learning transparently, I've put the starting files up as a new github repository and should be updating this on a regular basis as I work on it and learn new things. You can find the project at: https://github.com/simongoudie/Tracking/.

Three ways to save data in iOS apps

Simon Goudie — Sun, 26 Feb 2012 00:00:00 EST

Today I tested three different ways to implement data saving in a test iOS app. Here's what I got to work:

The save and load snippets here fit into the app by storing the data when a 'save' button is pressed, and recalling it when the 'load' button is pressed. In each case, the function is called with the text to be saved passed to it as the NSString object 'textToWrite'.

Using a file, text.txt:

+ (void) writeToFile:(NSString *) textToWrite {
    NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
    NSString *documentsDirectory = [paths objectAtIndex:0];
    NSString *filePath = [documentsDirectory stringByAppendingPathComponent:@"Text.txt"];
    NSError *error;
    NSLog(@"filePath = %@ and textToLoad = %@", filePath, textToWrite);
    [textToWrite writeToFile:filePath atomically:YES encoding:NSUnicodeStringEncoding error: &error];
};

+ (NSString *) loadFromFile {
        NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
        NSString *documentsDirectory = [paths objectAtIndex:0];
        NSString *filePath = [documentsDirectory stringByAppendingPathComponent:@"Text.txt"];
        NSError *error;
        NSString *textToLoad = [NSString stringWithContentsOfFile:filePath encoding:NSUnicodeStringEncoding error: &error];
        NSLog(@"filePath = %@ and textToLoad = %@", filePath, textToLoad);
        if (textToLoad) {  
            return textToLoad;  
        } else
            return nil;
};

Using user defaults:

+ (void) writeToFile:(NSString *) textToWrite {
    NSUserDefaults *prefs = [NSUserDefaults standardUserDefaults];
    [prefs setObject:textToWrite forKey:@"savedText"];
    [prefs synchronize];
};

`+ (NSString *) loadFromFile {
    NSUserDefaults *prefs = [NSUserDefaults standardUserDefaults];
    NSString *textToLoad = [NSString stringWithFormat:@""];
    textToLoad = [prefs stringForKey:@"savedText"];
    NSLog(@"Using defaults, textToLoad = %@", textToLoad);
    if (textToLoad) {  
        return textToLoad;  
    } else
        return nil;
};

Using property lists (some of this is copy/paste, but I think I get most of what's going on):

+ (void) writeToFile:(NSString *) textToWrite {
    NSString *error = @"Save failed";
    NSString *rootPath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) objectAtIndex:0];
    NSString *plistPath = [rootPath stringByAppendingPathComponent:@"savefile.plist"];
    NSDictionary *plistDict = [NSDictionary dictionaryWithObject:textToWrite forKey:@"savedText"];
    NSData *plistData = [NSPropertyListSerialization dataFromPropertyList:plistDict
                                                                   format:NSPropertyListXMLFormat_v1_0
                                                         errorDescription:&error];
    if(plistData) {
        [plistData writeToFile:plistPath atomically:YES];
    }
    else {
        NSLog(@"Something happened. Error message is: %@",error);
    }   
};

+ (NSString *) loadFromFile {
    NSString *errorDesc = nil;
    NSPropertyListFormat format;
    NSString *plistPath;
    NSString *rootPath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) objectAtIndex:0];
    plistPath = [rootPath stringByAppendingPathComponent:@"savefile.plist"];
    if (![[NSFileManager defaultManager] fileExistsAtPath:plistPath]) {
        plistPath = [[NSBundle mainBundle] pathForResource:@"savefile" ofType:@"plist"];
    }
    NSData *plistXML = [[NSFileManager defaultManager] contentsAtPath:plistPath];
    NSDictionary *temp = (NSDictionary *)[NSPropertyListSerialization propertyListFromData:plistXML
                                                    mutabilityOption:NSPropertyListMutableContainersAndLeaves 
                                                              format:&format errorDescription:&errorDesc];
    if (!temp) {
        NSLog(@"Error reading plist: %@, format: %d", errorDesc, format);
    }
    NSLog(@"Using plist at %@, textToLoad = %@", plistPath, [temp valueForKey:@"savedText"]);
    return [temp valueForKey:@"savedText"];
};

User defaults is obviously the easiest of the options, although it's probably also the least correct option to use in most cases. For this app, which is a simple text editor that can save and reload files, the file-based method is probably the most appropriate.