Embrace your weirdness and stop worrying

Once you’ve reached the point where you’re a proficient programmer with a good understanding of a useful tech stack, you’re now faced with the sisyphean task of Keeping Up with New Tech.

Polishing your professional skills becomes trendsspotting, starting with daily Hacker News browsing sessions to find out what’s going to be the new hotness, and then making sure you know everything about it. Or it is really? Frameworks and tools keeps multiplying like rabbits, and anybody claiming they’re up to date is profoundly delusional: something new probably came up as they’re saying it.

I’ve been thinking about how futile it is to feel like you’re missing out on something great in today’s tech landscape. There was an era when you could know everything about a programming language, but this time is long gone. What you really need is to stay sharp and keep exercising that learning muscle so you’re ready when something hard gets thrown at you. Every software has its quirks, and your job is to learn them and be productive, not to be perfect the first time you’re touching it. You’ll never be 100% ready for a new task, so they’re no point in sacrificing all your nights and weekends to this.

Let’s face it: as an interviewer, would you be more interested in a candidate that messes with the insides of old NES games for fun, someone involved in their community with a blog or open source software, or yet another person which only has a bunch of buzzwords to offer? If you try to be close to the trend in the hope you’ll stay relevant for the hiring market, it’ll only make you identical to everything else, and it will lead you to burnout. Good teams include a mix of people with different ideas and interests, and not just an army of clones.

I’m leaning more and more toward the idea that you should embrace your weirdness, run with it and have some fun. I’m prone to being too serious at times myself, but learning a bit more about making game or electronics is not a life-long commitment. It’s merely a good excuse to go out of your comfort zone and learn a new and interesting skill. Besides, you never know what could come out of it…

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:

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

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.

See the other articles in the series here