Detecting a Memory Leak/Bloat of a Huge Code Base

Few weeks ago, I was maintaining a product with big traffic when I noticed that Nginx processes were eating up the server memory on random occasions. Nothing consistent, and the exact cause is totally unknown.

I initially thought this might be a memory leak, and I started doing memory profiling locally on my machine. I had no luck doing so, for several reasons, amongst of them: Huge code base and the testing environment was nothing like the production one in terms of data size and user base.

Then I thought why not treat the running process as a black box and try doing some linux stuff, so I logged the memory stats using this command:

Which dumps the size of the current request memory. It was good enough, but I used a better wrapper that helped me test on several platforms, using NewRelic code:

I waited for few hours and watched the memory consumed by the process after each request. Then I found out that I had a memory bloat, where the code was loading thousands of records due to wrong query.

It was a fun experiment, finding which request was eating the memory was a tedious task, but treating it as a black box turned out to be the right way to inspect it.

The Configurator Developer

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.

What is it like to be a successful technical leader?


Being a successful technical leader is not limited to your technical ability. Your success exceeds your knowledge to your leadership skills.

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!




Very Recommended Resources

Two harmful mistakes every developer should avoid

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.



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.


Code QualityCode 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!

Joining N2V

Hello Dear Readers,

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 😛

Wish me good luck people :)

Installing CoffeeScript on Ubuntu

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:

Now give it a shot:

3 Factors for a Successful Startup

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))


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.


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.

Google App Engine, JRuby, Sinatra and some fun!

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.

Here are the steps:

Install JRuby, I’m using RVM on my machine:

Install needed gems, those versions are the ones which worked for me:

Create a simple app:

Now let’s create the following files (Please note that the following code can be further enhanced):


(fill the sender/receiver emails and the feed URL)



(You can set the period here, I’m using 15 minutes intervals)

Now, create an application-id at 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

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

If everything is OK, go to http://localhost:8080/notfiy and you should see “Done”.

Let’s go live now:

(the first time you execute this, you will prompted to submit the GAE email/pass combination)

It should now be running at, and in few minutes you should be receiving the first email. If not, go to app engine page then to Main >> Logs and check what’s the problem.

I like this stack cause it’s Zero cent cost, Zero deployment time, flexible, and it gives me exactly the freedom I want in terms of needed gems. Give it a shot, you won’t regret it!

Test or Regret!

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.


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.


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.

2011 and I’m back!


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.

Yes, now I can publish! C ya!!