I have been working recently on a little project where I had to hook together several 3rd party libs. Most of the time spent was about configuring these libs to make them work properly. Nothing fancy.

While working, it came to my realization that I have been working on similar projects recently, where most of the time is about gluing 3rd party stuff, and technical challenges are minimal.

The Configurator

For me, a developer who spends most of his working time gluing(configuring) 3rd party libs, is called a Configurator.

Now, don’t get me wrong, I’m not here to judge the nature of your work, since all of us have to do such type of configuring, maybe to try new things, quickly prototype something, or simply because we don’t have to reinvent the wheel. However, if most of your working time is going on configuring, then I do suggest you are not learning enough now. Actually, a question to ask yourself is:

What’s my competitive edge since anyone can do the same? Doctor Configuration?!!!

In such cases, I highly recommend that you dive deep from time to time in these 3rd party libs. Try to understand the code and the software design choices behind them. Try to fork and submit new new features.

Also, find time to start your own open source project. I have found that sharing code with others is the best way to become a better developer.

Bottom line, you need to realize whether you are in the configurator mode or not, and for how long. Based on that you can plan alternative paths.

Now, that you have a team to manage, work with and defend on, you need to be aware of the techniques that will soften everybody’s life, and of course make your career a successful one. This is something that’s harder than you might think as a start. There is a lot to learn and several skills to master.

I have gathered a collection of resources for you to read. I highly recommend that you read them and apply them occasionally. Best if luck!

There are several traits of a successful employee every hiring manager seeks for. There are as well several mistakes a developer should really avoid. Those mistakes usually cause much trouble!
When I set to hire someone, I tell him explicitly that I can’t tolerate 2 of those unless agreed upon during the sprint/iteration life cycle.

Deadlines

A Deadline is a major thing, I like to call it a : holy date. Many developers don’t get the importance of deadlines unfortunately. However it’s simple: all teams depend on this date, business, marketing, pm and finance teams. When you have a problem setting this date, you simply screw everyone’s life, starting by shifting business plans and then adjusting other plans accordingly.

That’s why I ask new employees to take their time in giving estimations. If you need time to research something, then fine: ask for it and take it.

Use Gantt charts to do estimations. A task time shouldn’t exceed 4 hours, otherwise you have to split the task to minor ones.

Add time margin to your estimation. Some developers tend to be optimistic. Certain problems might arise. That’s why I ask all developers to add a margin of 2-3 days depending on the sprint/iteration length.

If something is blocking you then you need to raise it ASAP. If for some reason you can’t meet a deadline, then raise it ahead of time.

Quality

Code quality is the most important factor in evaluating someone’s work. However, that’s not the reason of its importance. The importance of code quality comes from the old known fact; your code will be maintained by you or others in next iterations of the project.

If you deliver low quality code then, most probably the code will have to be rewritten after few iterations. Simply, you’ll waste months of planning and work.

However, code quality has no clear standards in terms of expectations. This is something that you need to consider and revisit every while and then. I ask team leads to set those standards in both design and implementation. Personally, I like both the SFEMS and the SOLID principles.

Pair programming is by far, the most reliable option for code quality. Testing is another one with a little cost of time at the beginning of practicing.

Both deadlines and code quality are so much important factors that help shapes the ninga of you. Please work on optimizing those skills. Stick to your team lead and take his advice when needed. It’s all about experience after all!

It’s my pleasure to announce that I have joined the marketing team of National Net Ventures — N2V , Amman branch. Therefore, I’ll relocate to Amman as well.
I’m excited to work with such a giant company helping entrepreneurs and fostering Internet industry in MENA region. Actually, that’s a part of my message in life.

I’ll give a hand in the technical efforts required by the marketing team to further expand the company’s work and message. Let’s see how things go

Unfortunately the current CoffeeScript package is for an old version. Thus, some manual work is needed to get the latest version working for you on Ubuntu. Here are the steps, we need to install Git, node.js, npm and finally CoffeeScript:

Startups, like everything in life, have some key elements for success. I’m listing here what I think are the most important factors to help you moving your idea to a successful startup.

((The order here is irrelevant and all have the same equal value))

Prototype

So you have the idea and you believe it’s the time to move forward. This is the proper time where you should prototype it. The purpose of prototyping is to collect enough feedback to decide whether you are going to continue and in which direction or cancel the idea altogether. Also, the prototype is helpful for marketing the idea and making relations.

The prototype should be the minimum work required to demo the idea for a group of selected people. Ideally the prototype takes 2-3 days of work. However, sometimes you need more time to demo the idea but in worst cases it shouldn’t take more than 2 weeks, otherwise you are actually coding the idea, not prototyping it, which is a totally wrong decision.
After you prepare the demo, pick a set of people including business guys and collect their feedback:

They do like it: This is the ideal situation. Congrats!

They kinda like it: This is the normal situation where you fix the workflow and decide your next step basing on the feedback you get.

They don’t really like it: This case is usually referred to as “Fail Fast” or “FF”. Don’t get disappointed, make use of the feedback and rethink the whole idea. Most likely you will start from scratch with a new startup idea.

Business model

Here is the golden rule:

Launch first, then figure out the business model is the recipe of disaster

Relaying on the “coolness” of the idea is a wrong thing. It’s all about business after all, and investors would like to understand how you are going to generate money. Actually not only that; they would like to see how confident you are when it comes to business model.

Start putting the business plan before you do any coding. Supported with estimated numbers, the business plan will help you take the proper decision at the proper time.Adding features, updating the product, marking, expanding to new markets or even seeking fund shouldn’t be arbitrary decisions. Instead, they should be taken when needed and based on your business model.

Team

Believe it or not, the team you pick might be the most important factor. The qualifications and the passion are the characteristics that you should look for. Even investors considers those ones, and that’s why you hear them saying: “It should be your bread and butter”. Many startups were bought or invested in because of the teams behind them apart from the business they do.

Pick your team carefully. Don’t fall in the trap of creating a bunch of geeks team. Instead, pick qualifications that you personally lack. Having a business guy or a marketing one working with you is highly recommended when you lack those abilities of talking or marketing your work.

Don’t underestimate the role of passion when you pick your team. Passion is the work soul, it drives the work flawlessly in good times and makes it immune in bad times. Many startups succeeded because of the team’s passion despite the bad times they faced, and vise versa, some of them had talents but lacked the passion and finally they failed miserably.

Feel free to add your comments on those factors and what you think might also be a missing one.

Yesterday I was experimenting with Google App Engine for a little project that I was working on. I literally started from ground zero and could do my thing after a long night. I’m blogging about it to share you the idea and save you some time googling solutions. So, here is the thing in brief: I wanted to parse some feed on periodical basis and send an email with new entries.

Looks like a 10 minutes with Nokogiri and cron jobs. Actually that’s true except of the fact that I need to pay for a VPS so that I can run the script with various gems (since I needed to do some work on the feeds before sending, but that’s for another topic) and for using cron jobs. Thus, I decided to try something new this time and I went with GAE since it has memecached that I can use as an LRU cache, also it has cronjobs and finally it has a mail system. I’m using JRuby and Sinatra for this project.

Now, create an application-id at appspot.com. Then go to Administration >> Permissions and make sure the sender/receiver emails play some role in the app. Personally, I granted them the developer role.

Now, go back to the source and modify the application-id in WEB-INF/app.yaml

application your-app-id

We should be ready now, start development server, watch the console and make sure no exceptions are there:

Yes, for god sake test! Whoever you are, a web/desktop/mobile developer please add automated tests to your work. If you don’t then your works is questionable.
Why? That’s what I’m going to answer in the next few lines.

Specs

Were you in the case where you or a new developer joined a team? Were you in the case where you got to work on a legacy code? Were you in the case where you forgot what your own code was doing?
All the above scenarios are normal during your lifetime as a developer or a team lead. All of them have a common shared thing: What is this code doing? and where to start?
Adding automated tests to the project code base, where a test case refers to a real world scenario that the code has to deal with, is the ideal answer for the questions above.
When you add a test scenario, then technically you are adding a new spec on how the code should behave in that scenario. When you add automated tests for some module, then referring to these tests is the first thing you can do to understand how/what this module is doing and behaving in different cases.The bottom line is that automated tests are your project specs.

Clean Code

A test usually checks the output/behavior of some method. Once you start testing you will find yourself in need to restructure your code in a way that you can test it. Technically, you will make sure the method is doing one thing and one thing only. One thing that can be tested like this: given some input x, the method should have some output y. Following this pattern(which technically you will be forced to when doing automated testing) will lead to a clean code, a code that doesn’t mix responsibilities and thus become harder to be read, updated and maintained.

Code Quality

New features will come, you have to update/refactor the code and then go and do some human tests to make sure everything you developed ever will work. This is called Regression Testing, test to make sure you didn’t break old code. Doing regression testing yourself is a natural thing and it will continue to be like that till your code base starts to evolve and evolve till you reach a level where doing a small fix in the code will make you scared to death before releasing since you have to do tens of human tests to make sure you didn’t break anything. Of course this will get worse if you are modifying others code. You simply(and really simply) can overcome this regression testing routine if you have a test suite for your code base that you can fire after whatever change you do to check what code is broken and what’s needed to be fixed. This will produce a robust code. Not only that, actually it will increase the code quality since whatever bug you have at some phase of the project, will be fixed and the fix will have an associated test scenario that will be added to the test suite. Next time when you update the code, the test suite will test that bug scenario to make sure you didn’t reproduce it again.

Agile Development

Most of the time you will have new requested features, or new discovered bugs. You have to add/fix whatever needed. Doing the changes and then doing human testing will consume your time and thus will slow down the project development and progress, and so will prevent it from iterating quickly. Having a test suite will save the time, and will complete the chain of Design, Test and Refactor methodology that Agile development poses. Actually some of you might think that adding automated tests will slow down the progress of development, which is wrong, very wrong. As a start it might slow it down, but after that it will save your time specially once your project starts to iterate with new features or bug fixing.

Conclusion

Test or you’ll regret! and if you want to do it, then do it right. I advice you to check Behavior Driven Development(BDD), a methodology of development that’s based on testing the behavior of your code.

It has been long time since I opened this page to write something. Actually 2010 was a very busy year. I left ArabCrunch team to join Inquiro, a cool startup focusing on SEO/SEM optimization, where my work completely took a different path and a whole shift. I became a team lead for a cool project using Python/Django stuff. Really enjoyed working there and loved the environment, I even had to cross half the planet(20 hours in air) to meet the managers and get acquainted to a whole new culture in life.

However, few weeks ago, I started to realize that I don’t belong to where I was working, since I always had the dream to do my own thing, always lacked the motivation. Yes, that was always the case, no motivation. Up till the cool ppl behind YallaStartup did a wonderful weekend startup event that I participated in. After that event things changed quickly and I decided to leave my job for my own startup. I’m spending whole time now work on my thing and I’m very glad to be so. In later posts I’ll describe what I’m doing in better details.

Now, I want to make use of this chance to express who much I missed Ruby and the whole community. Yes I really did. Now, I’m back and I’ll try to frequently update this blog with new life experience.

Just before I publish this post, for the little of you who are wondering whether Python is cool or not, indeed it’s very cool and so much similar to Ruby, but it lacks the great community that Ruby has.

Welcome to the fourth post of this series. Just before proceeding to the questions, I would like to mention the great Metaprogramming Ruby: Program Like the Ruby Pros book by Paolo Perrotta, a very good book that explains the metaprogramming aspects of the Ruby language.
Now let’s get going!

Scope gates

Taken from the above mentioned book:

There are exactly three places where a program leaves the previous scope behind and opens a new one:
• Class definitions • Module definitions • Methods
Scope changes whenever the program enters (or exits) a class or module definition or a method. These three borders are marked by the keywords class, module, and def, respectively. Each of these keywords acts like a Scope Gate.

The question text is:
If block is a closure, why this code does not work? And how to make it work?

def R(arg)
Class.new do
def foo
puts arg
end
end
end
class A < R("Hello!")
end
A.new.foo #throws undefined local variable or method `arg' for #<A:0x2840538>

The answer is:
Blocks are closures and arg is indeed available inside the Class.new block. It’s just not available inside the foo method because def starts a new scope. If you replace def with define_method, which takes a block, you’ll see the result you want:

def R(arg)
Class.new do
define_method(:foo) do
puts arg
end
end
end
class A < R("Hello!")
end
A.new.foo # Prints: Hello!

Almost everything in Ruby is an object

The question text is:
“Everything is an object” was one of the first things I learned about Ruby, but in Peter Cooper’s Beginning Ruby: From Novice to Professional book, it is mentioned that “almost everything in Ruby is an object”.

Can you give me some examples of things that are not objects in Ruby?

The answer is:
he most obvious one that jumps into my head would be blocks. Blocks can be easily reified to a Proc object, either by using the &block parameter form in a parameter list or by using lambda, proc, Proc.new or (in Ruby 1.9) the “stabby lambda” syntax. But on its own, they aren’t objects.

Another example are built in operators: while methods are objects, some operators are not implemented as methods (and, or &&, ||), so those operators aren’t objects.

Hash keys

The idea here is that whenever you want to define your own keys types for Ruby hashes, then you need to define 2 methods #eq? and #hash for those types.

The question text is:
I have a class Foo with a few member variables. When all values in two instances of the class are equal I want the objects to be ‘equal’. I’d then like these objects to be keys in my hash. When I currently try this, the hash treats each instance as unequal.

Hash uses key.eql? to test keys for equality. If you need to use instances of your own classes as keys in a Hash, it is recommended that you define both the eql? and hash methods. The hash method must have the property that a.eql?(b) implies a.hash == b.hash.

The eql? method is easy to implement: return true if all member variables are the same. For the hash method, use [@data1, @data2].hash

This gem is a wrapper to send push notifications to devices. Currently it only sends to Android or iOS devices, but more platforms will be added soon. With APNS (Apple Push Notifications Service) you can send push notifications to Apple devices. With GCM (Google Cloud Messaging) you can send push notifications to Android devices.