As any veteran programmers would know, one of the most important skills (among a multitude of skill requirements) to master is the art of debugging an application. Chapter 19 provides an excellent coverage of this topic in the context of iOS apps. Beginning with a conceptual introduction to LLDB (Apple’s Lower Level Debugger) and the difference from the older version of the debugger – GDB – the chapter introduces the intermediate programmer to the actual mechanics of debugging with LLDB and the use of breakpoints (which is no different from the use of breakpoints from many other advanced editors or debugging tools).
Having mucked around with almost 5 conceptually simple iOS apps, I am no strange to using breakpoints to zero in on problems. What is interesting, however, is the detailed explanation of different types of breakpoints – exception breakpoints, symbolic breakpoints. Of particular interest and of learning value to me personally, is the use of Ctrl-Click + “share” on the breakpoint to write a breakpoint state into a `xcshareddata` directory, which can be saved into git and so shared with a fellow developer.
Watchpoints are also interesting to me, being useful for specifically tracking data mutation events – particularly for global variables that have changed, in the context of Singleton implementations, Core Data persistent store coordinators or API engines.
Advanced Use of Debugger through Python Scripting
For our normal, simple use cases, introspecting objects at breakpoints is a simple matter of typing
For scalar variables (e.g. integers or structs), we will of course use
p (int) self.myAge
p (CGPoint) self.view.center
What if we need to search through a very large array containing a large number of objects? This is where we might have problems manually reading the 10,000 objects that are printed out. In such a case, we can actually use Python to run a search. Jumpt into the python shell prompt from the lldb prompt by typing “script”. Then, via the great example from the book:-
>>> import mypython_script
>>> array = lldb.frame.FindVariable("myArray")
>>> yes_or_no = mypython_script.search_object(array, "<search element>") # search_object is a method we write in our custom mypython_script .py file.
>>> print yes_or_no
This nice little trick from the book goes straight into my personal bookmark.
The chapter ties up neatly with an explanation of how NSZombieEnabled flag/environment variable is used to track objects in memory, a summary of various types of Application crashes one commonly encounters and how crash stacks can be collected – “natively” via iTunes as well as on 3rd party services like TestFlight and HockeyApp.
RaspberryPi is a tiny little (credit-card size) ARM/Linux box which has caught the software/hardware/linux communities by storm. Here’s an image from raspberrypi.org that explains exactly what this tiny little machine does:-
The hacker community in Singapore is in full-blown Raspberry Mania with our inaugural Raspberry Jam held at Hackerspace.sg on the evening of 19th July. To quote RaspberryJam.org.uk, a
Raspberry Jam is a rapidly growing global network of user groups that meet every month to support hobbyists, developers, teachers, students, children and families – in fact, anybody that would like to put their Raspberry Pi to good use.
I have been wanting to mess with this cute little machine with my daughter since I heard about it back in December 2011. With its simplicity, barebones approach and low low cost of USD25.00, it was the perfect vehicle, in my opinion, for introducing her to the notion of computing.
Getting my linux OS into the RaspberryPi was a simple matter of running `sudo python raspiwrite.py` and selecting the appropriate linux distro (specific flavor of a linux operating system) and the script walks you gently through it. Fortunately for me, Debian distro and Arch Linux (arm) distro are both my favorite linux distros; and getting Debian up-and-running (from my Mac OSX machine) was particularly a brain-dead affair. Get started by downloading the raspiwrite.py script from http://exaviorn.com/raspiwrite/. Alternatively, if you are a pro hacker with git chops, get the latest and greatest version of raspiwrite.py from https://github.com/exaviorn/RasPiWrite.
RasPiWrite: your Debian distro set-up via a simple Python script
Once you have gotten your script, insert your blank SD card into your SD card reader connected to your machine, launch your terminal, cd into the RasPiWrite directory to run `sudo python raspiwrite.py` and you should be guided by this well thought out python script and, for now, we will choose the simpler Debian option:
Once done, all we have to do is to plug our Debian-powered SD card into the RaspberryPi’s SD card slot, plug in a 5V power cable into the micro USD, connect a mouse, a keyboard into the USD ports, hook up a HDMI display device (which in my case, is a small, portable projector with a HDMI port) and we will have our little machine booted up. Our installed Debian image comes with LXDE desktop environment, so it was a simple matter of booting up our machine, logging in with the image’s prescribed/default user name and password and launching LXDE via `startx`.
Here’s the debian LXDE desktop in all its glory:
Arch Linux ARM for the advanced Linux users… or Beginners who are brave enough to venture! :-)
Since Arch Linux is my favorite linux distro, it was simply impossible for me not to go down this road; especially since RasPiWrite has gotten it nailed as one of the easy-to-install option.
Bewarned that this Arch Linux ARM install for RaspberryPi does not come with a desktop manager. This means that when you are done, all you really have would be the command line :-)
If this sounds really fun for you, read on!
Following the exact steps above with RasPiWrite, the first problem you will encounter, after the command-line step-by-step guide, will be:-
:: Starting Secure Shell Daemon [BUSY]
Could not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Disabling protocol version 2.
Could not load host key sshd: no hostkeys available -- exiting. [FAIL]
Well, this shouldn’t scare us off because
You are a smart, clever boy/girl, ya? (encouragement for the Kids!!! think of the children!!!!!!!) :-)
Arch Linux’s wiki is famously detailed and the Arch Linux forum users are crazily helpful
Well, for the uninitiated (windows users and mac users not acquainted with telling your computer what to do with typed instructions in command line), the error message is referring to a process which all linux operating system uses. This little background software is called “ssh” (Secured Shell, like what the first line of the error message says) and it runs as a Daemon (background process, behind the scene when your operating system starts up) to allow a user to securely “login” to a machine. In this case, our RaspberryPi’s Arch Linux ARM operating system (which we have just installed) is having trouble loading up this sshd (Secure Shell Daemon).
And so it appears that this Arch Linux ARM Operating System image that we have installed does not have a functioning ssh program. The prescribed solution is simply to connect our raspberrypi to an internet connection via its ethernet port and then run:
The first command `pacman -Syy` tells our arch linux arm operating system to synchronize the latest open source software with the freely available open source repositories on the internet.
What the long, second line does is to remove any trace of the current openssh program (software “package” is the commonly used term), including other software libraries (dependencies) that it uses, remove all its associated files in /etc/ssh directory, install it all over again and then start up the daemon (the software “process” in the background).
`pacman` is the software “package manager” used by Arch Linux operating system (o yeah, I love operating systems with a sense of humor! And for the arch veterans, you and I know there’s a little easter egg here ya? shhhhhh…). This command sounds scarily convoluted, but all it does is pretty much what you would do on a computer running windows or Mac OSX when you “click on a link” on a webpage to download some software that you want to use, and run the installer which comes with a graphical user interface. In this case, we are simply giving instructions to remove the outdated copy of the “ssh” (openssh) software, and reinstall it with a fresh copy and then start it up immediately.
Once done, we can reboot and you will find that we no longer have that scary error message.
At this point, however, we are still messing around at command line! This is perfect for advanced users who are familiar with administering remote servers and is used to dealing with “headless” (no Graphical User Interface) operating systems and simply wants a clean, barebones installation with bare minimum software so that we can be very very specific about exactly what other type of software we want to install/run from pacman (remember, Arch Linux’s open source software package manager). For a small little machine like RaspberryPi, I imagine this would be exactly what most advanced users expect to use it for.
For those who would still like to have a GUI, we can of course use Debian (or Fedora), or we can still set up a Desktop environment (with wonderful Graphical User Interface that we are used to on Macs and Windows PCs).
This USD25 piece of wonder, like Arduino before it came about, has changed the landscape for small devices. In recent days, a whole range of similar devices from Korea, China (There’s one called “Gooseberry”!) and many other countries will revolutionize what people can create with software and hardware.
Unlike Arduino (microcontroller-based), RaspberryPi is microprocessor based with a full fledge operating system running on it. Already creative and talented software/hardware hackers are making waves with RaspberryPi-based creations like a remote-controlled car -
In a small team of technical team comprising system admins and application developers, an artificial boundary of control has traditionally been set up to segregate the roles of application development and system administration – for good reasons.
But as technology frameworks progress and the delivery of an application’s service becomes increasingly user-centric, the hierarchy of a technical team inevitably flattens and developers and system administrators alike have to deal with change in a more dynamic manner and increasingly focus on an “ask for forgiveness, not permission” collaboration model.
What does that mean in simple terms?
When a new feature or a change is ready for release by an application developer, he/she should not need to ask for the system administrator’s intervention to do so. At the same time, to ensure that the new application features do not break the existing code or affect the quality of the existing service, various tools need to be in place – which will be the subject of future blog posts.
The most basic of all deployment configuration that needs to be made available to individual developers in a team is the `sudo` command on the staging or production machines (servers).
Getting the system admin to enable `sudo` rights for a new/incoming developer is traditionally a boring, manual process involving running the `visudo` command and manually enabling (commenting out) a specific unix/linux group in the /etc/sudoers file and then assigning the new developer’s unix/linux user account to the corresponding group.
Imagine repeating this multiple times if you have multiple instances of servers to manage. Such code bureaucracy is not only unproductive, it takes up valuable time which a skilled System Administrator can otherwise spend on scaling the application’s infrastructure or on helping application developers to improve their code quality .
The solution is to automate these mundane configuration tasks in a set of fabric scripts and this also has the benefit of ensuring consistency throughout the team; and then empower various senior developers in the team (who also have root access) to get a new user added in, in 5 seconds flat.