Figuring out how the CSS of a website works using Firebug – Screencast

The basis of using Cascading Style Sheets (CSS) to apply formatting to an HTML document is deceptively easy to understand, but hard to master. You define selectors that designate HTML elements, which contains formatting rules that apply to those elements and their children. If more than one rule applies to an element, they are applied using a priority order, from the more general to the more specific: that’s where the “cascading” part comes in.

It’s almost impossible to predict how a website will look by looking at the code. If you have to modify the CSS of an application you don’t know “just” to change a color or a font size using only your text editor, you’re out of luck. Figuring out the priority of each selector is complicated if you have many stylesheets that applies to a page, and you can easily miss a more general selector. You can’t just look at an element on the page and immediately deduce which CSS rules are affecting it, especially if there are many contradictory rules.

That’s where tools such as Firebug for Firefox or the Developer Tools in Chrome comes in. Among many other great features, they allow you to see which rules are affecting a particular element on the page, and to modify them on the fly.

Of course, it won’t modify your original CSS since it only changes the local copy in your browser, but you can quickly test what’s the impact on your page and then make the modifications. You can also use those tools to explore your favorite websites and see how they used CSS to format elements: it can be a great learning tool if you’re looking to grow your CSS knowledge.

Here is a screencast on how to use Firebug to figure out where the colors are defined on the Twitter website:

Want to learn new programming skills quickly?

Subscribe to my newsletter to receive my 5 Hacks to Learn New Skills email course directly in your inbox.

You’ll also receive updates about what's going on with the blog.

How to get started with Android development – Basic structure

andro02In a previous article, I wrote about how you can launch your first Android application from the samples provided with Android Studio. Now that you’ve had a chance to poke around a few samples, I’m going to tell you a bit about the basic structure of an Android application.

A good place to start understanding an application is the manifest. The AndroidManifest.xml file links all the parts of an Android application together, including:

  • The activities contained in your application,
  • The theme you use,
  • The name of the application and its icon on the main screen,
  • The permission the application must request to run.

Activities and the java folder

The Java code of your application lives in the java folder. The first class you’ll create is a Activity class, which is the main building block of all Android applications. An activity is a full screen window in which all your code will run. Each activity has it own life cycle which starts when it’s first launched and last until it is finally destroyed.

The user navigates between different activities in your application: the back button of the device closes the current activity by default and goes back to the previous one. If the user closes the first activity of your application, he’ll go back to the application that was previously open, if any. You can also launch other applications (with their own activities) using intents. You can use this to request an application that can send an email or play music, and the installed applications that can manage this will be displayed to the user.

The activity life cycle can be affected by events outside your control: for example, if a phone call comes in, your current activity (so your application) will be paused. Each activity has a layout associated with it that describes how controls that are displayed, and the activities are declared in the AndroidManifest.xml file.

Unfortunately, the fact that the activity is bound pretty strongly to the navigation AND to the user interface/layout makes it hard to separate the business logic and the display logic properly. You can create a usable Android application with only a .java file with an Activity class, but eventually you’ll want to move on to a better architecture. There are some patterns out there that can help you do this, but for your first application you should stick with this and avoid introducing additional complexity.


Resources are everything that your application needs that is not Java code, such as layouts, strings, images and other constants. The Android API uses XML for most resources. The res folder contains all the resources of your application, such as:

  • XML layouts for each activity and component in the layout folder, styles in the values\styles.xml and images in the drawable folders. Layouts in Android are inspired by HTML/CSS, so if you’ve ever done some web development you’ll feel right at home pretty soon.
  • All the strings used in your application in values\strings.xml. You can hardcode them in the layouts, but if you ever need to translate your application you’ll be glad you put them all in one place to get started with.
  • Menus for your application are defined in the menu folder.

You can now understand all the basic parts of an Android part, and start creating your own application!

Writing a book: how to work on many projects

After quite a bit of pondering, writing and editing, I shipped the Learning as a Software Developer book last week. The whole process took about 6 months to complete, so I had time to experiment with a few ways to work. During that time, it was important for me to keep the blog going and still have time for technical learning and my various homestead-y hobbies. So, in that case, I was in for a marathon, not a sprint.

Spoiler: making a commitment to write regularly was the best way to make progress.

I’ve also tried a batching approach to the problem. The idea was to write a few blog posts in advance the first week, then spend the next week working on the book, and finally do a bit of technical learning. It was working decently at first and I WAS able to batch a few posts in advance, but then life happened and I was only able to write a little bit for the book before having to go back to blog posts. Fail!

Making sure I’d work a bit on everything each week was the best way to make sure I’d keep moving forward. It kept everything fresh in my mind, so I had less catching up to do to go back into the flow and start writing. To limit context switches, I’d pick ONE thing to work on every night instead of jumping from task to task.

important-writingI’m aware this makes me less effective than batching, and that it takes more time to complete some projects, but this way I don’t lose steam and burn out. Right now, I’m living in manager space and not in maker space: I don’t have time to focus intensely on a project for hours every day, so I have to sprinkle important projects here and there to make sure they get done. If I space out working on each project too much, I’ll wake up 6 months later without having published a new blog post or written a newsletter.

Relating to this, I also had to hone my ability to get to work immediately (or at least faster) since I’m working during the gaps in my day. I only have a block of a few uninterrupted hours in the weekend if I’m lucky, so I can’t lose 2 hours getting started every time.

The key here is to have a task primed and ready to go, or at least a well-defined process. For example, to write a blog post, I generally write a draft in one go, and then edit the next time, so I’m either starting a new blog post or completing one.

Finally, what helped me is that all those tasks are similar enough to fall into the same habit. I changed my blogging habit to a habit of writing and coding using the same cues and rewards, so I’ve not lost a habit that took some work to build. It took quite a while to ship everything this way, but in the end it was worthwhile and allowed me to ship the first version of the book to you.