3 January, 2017 - No Comments!

2016: A Year in Review

2016 wasn't easy, but it was amazing and full of adventures. Seeing amazing landscapes, experiencing unique cultures, and meeting amazing people along the way.

I started last year by working my ass off as a freelancer, working 12+ hours a day. But I was able to ...

  • Travel to 6 countries (Georgia, Turkey, Indonesia, Malaysia, Vietnam, Germany), and more than 30 cities.
  • Eat beautiful and weird stuff, from Khinkali in Georgia, to fried Silk worms and snake's beating heart with it's blood in Vietnam.
  • Climb 4 mountains/volcanoes (Mousa in Egypt, Batur and Agung in Bali, Fansipan in Vietnam)
  • Learn photography, freediving, surfing, and riding a scooter.
  • Swim with sharks and stingrays in Malaysia, and swim inside USSR ship wreck in Bali.
  • Buy my first camera (Sony a6000).
  • And finally, moved to Berlin.


Also, last year, I barely completed my reading challenge. These were the ones I really enjoyed.


  • Ready Player One by Ernest Cline
  • ★ Dune by Frank Herbert (Read the first three, but the first as my favorite)
  • ★ Foundation series by Isaac Asimov (Second Foundation is my favorite)
  • The Alchemist by Paulo Coelho
  • Departure by A.G. Riddle
  • The Graveyard Book by Neil Gaiman
  • Neuromancer by William Gibson
  • 1984 by George Orwell
  • Fahrenheit 451 by Bradbury, Ray
  • A Clockwork Orange by Anthony Burgess


  • ★ Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration by Ed Catmull
  • Sapiens: A Brief History of Humankind by Yuval Noah
  • Superintelligence: Paths, Dangers, Strategies by Nick Bostrom
  • Ghost in the Wires: My Adventures as the World's Most Wanted Hacker by Kevin D. Mitnick
  • Death Throes of the Republic by Dan Carlin (Podcast, but it's long to be considered an audiobook)
  • Living with Complexity by Donald A. Norman
  • It's Not How Good You Are, It's How Good You Want To Be by Paul Arden

31 December, 2015 - No Comments!

2015: A Year in Review

Thanks Tobias van Schneider and Leo Babauta for the encouragement.

This year, I was able to…

  • Read and listen to more than 100 books. I started a reading habit that became an obsession, and started getting into fiction, philosophy, and history.
  • Meditate daily for more than 6 months. It was very hard to just sit down, especially because of my racing mind, but I managed to do it for long and felt amazing.
  • Do some local traveling. Kicked of the year going to Siwa, were I spent most the time freezing. And managed to explore parts of Islamic Cairo.
  • Conquer my TV/Movies addiction. I stopped watching all the okay show/movies (only the best), watch one show at a time (follow one story), and watch it after the season ends (no cliff hangers). Only exception to the last rule is Game of Thrones, and comedy shows.


  • Shaving my head, completely.
  • Writing in a diary. I like to write in 3rd person, like Tim Ferriss and Bréné Brown suggests. It helps to gain some perspective, see things from another point of view.
  • Getting more organized. I started creating lists, templates, and checklists for everything. And started passive and active time tracking, using RescueTime and Harvest, which helps see time leaks, and improve estimation ability.
  • Drawing, again. I’m now learning and practicing my drawing skills daily. Focusing on drawing simple comics strips and cartoon characters.


  • Basic Spanish, but cannot speak, yet.
  • How memory works, and improved it. Which is considered huge for me, because I’ve always thought I had bad memory. I also learned some tricks like Mnemonics & Memory palaces.
  • How to read faster. Depending on what I’m reading, sometimes it’s a matter of searching and scanning for bits of information, and sometimes by Conceptualization.

Favorite Podcasts

  • Dan Carlin’s Hardcore History
  • The Tim Ferriss Show
  • Serial


  • Saga
  • Y the Last Man
  • Attack on Titan


  • Man on Wire
  • Sunshine Superman
  • Jiro Dreams of Sushi


  • The Martian
  • The Dispossessed
  • Snow Crash
  • The Fold
  • Armada


  • Zero to One
  • Design is a Job
  • Genghis Khan and the Making of the Modern World
  • Surely You’re Joking Mr. Feynman
  • Moonwalking with Einstein
  • Man’s Search for Meaning
  • We Learn Nothing

“Learning to ignore things is one of the great paths to inner peace.” — Robert J. Sawyer

“The first principle is that you must not fool yourself and you are the easiest person to fool.” — Richard P. Feynman

“Live as if you were living a second time, and as though you had acted wrongly the first time.”— Viktor Frankl, A Man’s Search for Meaning

Thank you!

26 November, 2014 - No Comments!

What Podcasts are you listening to?

My Favorite Podcasts

Lately podcasts seems to be getting some attention, so I thought I would share my favorite Podcasts.

  • Dan Carlin’s Hardcore History. This one is my favorite. I wasn’t interested in history before, but after listening to Wrath of the Khans series, I became addicted, and I’ve been listening to previous episodes since. The best thing about it is that Dan Carlin tries to draw a scene of which you get immersed into.
  • SERIAL. Most popular podcast on iTunes. It takes you through the journey of investigating a true story murder-case by talking to people involved and reviewing the evidence. It will leave you wondering each episode over who did it.
  • StartUp Podcast. Same theme as SERIAL, but instead of investigating a murder-case, it’s about documenting the process of starting a business without knowing anything about starting one. It shows the struggle and inner conflicts that startups go through.
  • The Vergecast. Wraps-up the The Verge’s weekly topics. It’s fun to listen to, and saves me from reading a lot of articles online.
  • DRT or Dorm Room Tycoon. This is the oldest podcast I’ve been listening to. It has awesome interviews with different people in the tech industry about business, design and technology in general.

What’s yours?

22 September, 2014 - No Comments!

Enhancing your Ruby experience

Writing more readable ruby code

Best thing about ruby, is that it’s clean. You feel more writing english than writing code. Sadly I didn't realize this before, and if you are new to ruby and rails. You're probably writing code like this …

It might look normal to you because you're used to it by now, but it has adds overhead when reading. You have to read every line translate it, keep variables flow in mind, and remember what each function does. And if you have like 20 lines, that would be even more pain in the ass.

Instead why not write instructions directly. Why not say what you want to say in plain english.

This doesn't eliminate the coding part. It just gets it deferred to private methods. When reading public methods, you don’t care about the flow of variables or which method gets called, you only care about the big picture.

This helps by making public methods scannable, something that you can read. Something you don't have to compile in your mind.

It makes your code DRY, and constructed of small single tasked reusable methods.

To wrap up

  1. Move all class calls and assignments into small private methods, each responsible for one small task.
  2. Write more descriptive method names, it’s ok to have long names, but not very long. Take your time thinking about it, and make sure that it’s clear what the method does. e.x. authenticate_using_email, sorty_by_popularity, filter_by_author, …etc.
  3. Prefer use of instance variables (@variable) for global assignments over passing parameters, and assigning them back to another variable.
  4. Optional: Use rubocop to help you follow Ruby style guidelines.

Do you have a better way or tips on enhancing this? would love to hear your thoughts

If you find this helpful, don't forget to hit Recommend button

13 January, 2014 - No Comments!

4 Things I wish I knew when I started Rails

Or MVC in general

Ruby is awesome, and Rails makes it even more awesome. I started my journey with Ruby on Rails about a year ago in order to make an API for asknative app for iOS. Before that I only did very little PHP and mostly frontend stuff. Anyway, here is what I wish someone told me when I was getting started.

1. Cache from the start

Caching is critical. If you didn't cache from the start you are never going to cache. Caching is a pain in the ass, and as long as you delay its going to be harder to add. Thinking that there is no need for adding cache, when you are getting started because there is no complex queries yet. Is the first step toward a bigger problem later.

In our case, we tried to add caching later in the process, and failed to do so. We've spent around 3 weeks trying different solutions with no luck. We ended up delaying this issue again, because the serialization gem we were using was not very handy with external cache, and requires to use its caching layer. Their caching system didn't work well with us, and they were rewriting their gem again to improve it and rethinking about cache. So now we either remove this gem or just wait till they add caching.

I'm not blaming them for that, it’s our problem that we didn't find out about this from the start. So do yourself a favor and setup caching from the beginning.

2. Never slack on Testing

Startups is about sprinting. Features will be added, modified, and removed and it has to be done fast. We tend to think the testing is an overhead. Maybe because your tests take too long to run. Maybe because you see the time take for adding necessary tests will be a waste of time. Maybe because specs are going to change anyway. Or maybe you are so confident of your code that you don't need to test your code.

The moment you say we'll do tests later, you are surrendering to your code. Testing is never a waste of time. And it is very important specially when you are in a startup. Because there is alway a constant change it means that you need to have a way to be 100% confident when you apply those changes to production.

“Move fast and break things”

Of course, but that doesn't mean you should do it intentionally.

Testing is tedious, takes time and effort to do it right, not fun, and sometimes it takes longer time to fix testing bugs. But having tests will make you the owner of your code, not a slave to it. Scared of touching your code or others code not to break anything. Scared of pushing to production, because you have to test it over and over to make sure nothing breaks.

3. Lazy requests

In any request, avoid doing any work as much as possible. If there is a task that is not directly related to the request, it should be running in the background as a worker.

Lets say there is a request that should update user profile. You only need to validate the data, then return ok to the frontend. Unless you are working with sensitive information, there is no need for the extra delay added for inserting or updating record in the database. Even if the request only sends one request to the database there will be callbacks and triggers firing all over the place before, after storing.

Maybe you're afraid that something would go wrong after accepting the request and you have to be absolutely sure. But how often does that happen? Lets say 90% of the request will get accepted, so why not make it faster for those people. Why do we have to make them suffer because of that?!

4. Put your code on diet

Thin controller, Fat model

“Thin Controller, Fat Model” OR “Just move all your logic to models. It’s that simple.”

These are the worst advice ever. I don't know why a lot of people in the rails community are recommending this, but it has to die. Models are not your magic bag.

At first I was using models for everything. Everything that does something that used to be in the model. But browsing the model was nightmare. Attributes, queries, callbacks, validation, methods. One class rule them all.

Moving to Concerns seemed like a good option. After all its added by default in Rails 4. Moving all the common code in there, even it was used as a component for new features. Models looked much better, but then we realized that concerns is hiding under the rug. At some point scopes were a mess. And adding logic that talks to different models there makes the matter worse. Concerns are useful in very little cases, like having same attributes share between models, maybe queries too (but it’s arguable)

Micro API

MVC is great, but its not enough. Don't limit your choices to either make fat controller or fat model, it will make your code harder to maintain. If you have bunch of code that needs to do something specific with many models, why not just create an object for doing that. Has its own api, and does a simple task, and thats it.

Working with single responsibility objects makes it easier to test, easier to read, easier to modify, easier to replace.

People used to put logic in controller for a reason. It can tell a story. If you read a controller you should have an overview of what it does. And its a good practice for the upper layer to control the ones below, and avoid same level objects to communicate to each other.

Having a middle layer between Controllers and Models minimize if not eliminate any logic in the controller, controllers will be more like a story. And changing models will not affect controllers because it doesn’t know about models. Service objects become like a genie, controller asks, and service objects will make that happen.

This applies to the Views too. You can add View Models or Presenters to pass the data into your views. Without making your views know anything about the models, relations, or how to format the data. Views will be so dumb that you don't have to test.

The less each layer in MVC knows about each other the better. If you changed your database from MySQL to MongoDB it won't matter. Each layer will be independent, and applying changes will be much easier.

To recap

  1. Think about caching from the start and get it to work.
  2. Never submit code without it’s tests.
  3. Never work with database in a request unless its absolutely necessary. Other than that, throw it in worker in the background.
  4. Use PORO (plain old ruby objects) to create layers that separate each part in MVC.

If you find this useful, please share it ☺

20 May, 2013 - No Comments!

Read it Never

A web & mobile app that holds all articles you don’t want to read now.

“Pocket”, “Instapaper”, and “Readability” are all amazing tools for nothing. I love to use them, same as you. But they help you not to read anything. Problem is a combination between people and the concept. Whatever application you choose at the end the result is the same. You will endup not reading anything.

It all started with a cool concept of reading things later because people are too busy to read now. So something came up, others thought they could do better, created mobile app, came up with minimal UI, another rebranded, and so on. But no one actually stopped to think for a solution to the real problem. What all those services do is making the their interface is better and easier. But what is the real problem?

You start off with a new cool read it later. You start collecting interesting stuff whenever something comes up. At first, RIL is very handy and you’ll keep up for a while; until you get busy with something. You’ll keep adding, until it becomes unreadable. All those article and videos, important and unimportant one will be in one nest, too scare to even look at. So you endup leaving this service for another new one and fresh one, and the cycle begins all over again.

Procrastination. I don’t know if that’s really their goal. But they are not really about reading it later, they are about getting your mind of distractions. Which is pretty cool, but what about important articles and stuff you kept saving.

It’s not easy to come up with something that will revolutionise procrastination. Something that understands you. But lets see what we need. A service that can save article and media for later, gives you important stuff relevant for you, and doesn’t accumulate.

1. Social. It doesn’t need be with relations but it needs to know who are you connected to and see what they save, see what everyone saves, and connectes you with people with same interest. This graph is private for the api to get recommendations and rate articles for you.

2. Sorting mechanism. Like Hacker News and layervault’s Designer News, first thing you see should be popular —base on your interest not views and likes of everyone. So you don’t miss anything important, and if you are starting to read, its better to start off with something interesting to get you started with reading.

3. Maintain itself. With all the data it have from your graph, it should have pretty good understanding of what you want and don’t want to read, also with the rating for each article it would also help know which one to discard. Think of it like a garbage collector. If the rating is low, and there is no interest based discard it after a week. If it just just one of the variables leave it for a month, then discard, but if the rating is high it can be left for couple of months. The longer its there the less rating it will get.

The good thing about this, is that you’ll get motivated to read before things disappear, and if you can’t read now, you know you can catch up in no time.

Apps should be smarter than just a database, and not being social is not acceptable anymore. This is just a draft of a problem many of us are having. I believe RIL services can do better because they have more data, and people who can test this hypothesis. They can ignore the problem but at some point, someone will stop and think “Read it Later is broken, How can I fix that?” then act on it. Same as what Mailbox did.

15 April, 2013 - No Comments!

Photoshop sucks

a lot of memory of course.

When I use it i can’t open anything else. Even with a 8 GB Ram, it hogs it all.

So from here on, I’m going to use Pixelmator for all Graphic Design. I’ll use Sketch for UI, but thats for later.

Its simple, easy, and got a lot of cool effects. Its not good in UI, but its amazing in doing graphic work.

14 April, 2013 - No Comments!

Forget everything, and immerse in isolation

By default, people multi-task. It’s been proven ineffective by many researchers; yet people ignore all those evidence and keep doing it. Anyway thats not the case with me.

I know that i’m a uni-tasker, and I was happy doing it for a while, but multi-tasking just can’t accept that. It keeps buggin in from time to time, asking me to check this, and do that, and with the easily distracted mind of mine, I lose the battle most of the time.

Problem lies in external and internal distractions.


The solution I found for internal distractions is to …

  • Clean your desk for only papers and stuff you’re using, and everything else out of sight
  • Use one paper to contain all tasks
  • Other papers for detailed representation of your thoughts.
  • Empty your Desktop, but keep documents that your working on or folders that your regularly access. (I use aliases for internal folders and put them on desktop)
  • Dock for apps that run 80% of the time
  • Launchpad for regularly used apps, one swipe away (Typing is fast but i’m lazier than to type 2 letters for opening an application)
  • Fullscreen Apps
  • Fullscreen browser with relevant tabs, or Presentation Mode with random ones
  • One mode at a time. If you design, then leave only design related apps, if you code then leave all code related apps. Don’t leave apps running in background.
  • Downloads is my inbox for everything. Dump is for random stuff that I don’t need, nor i want to delete them




This kind of distraction seems inevitable, because anyone can call you for needing something, or co-workers interrupts to ask you about something.

For me I solved it by …

  • Flight mode or Don’t Disturb for focus periods.
  • Setting time for conversations. If your chatting, have a time limit for it. Then close your client, then check in after 3-4 hours depends on your time of focus
  • Closing personal email or notifications. I mainly use it for newsletter and registration
  • Silent work email. Close desktop client, but leave your phone client on silent, so after you finish your focus session, you can check it out
  • Leave email open for a specific period of time, if you’re having conversation. (It’s rude to leave someone hanging on the other end)
  • Avoid chatting. Because it takes a lot of time in side conversations. If want to communicate written words, email is very efficient, but if you want to explain something long and complicated, have a voice chat.

What’s the point?


Focus is the most important thing while working is to have those pure couple of hours. You can spend a day trying to solve a problem while it could’ve been done in just one hour. It’s not by the amount of time you give in, it’s the quality of work you get out.

Even if you love your work so much —as most of us do— Work is work, it’s tiring and sucks the life out of you. Try to grab best time to work, and dive right in for couple of hours, get back up, take a breath, connect with others, then get back down.

I tend distribute work across the day. To have couple of hours in the morning from 8-10, another session after my workout at 12-4. And final one at night around 7-9. This I consider too much work. So for you may be as short as 4 hours a day (If you are a designer). Change all you want but try to keep time from 20 minutes to 4 hours.

Respect your time before you ask others to respect it.

30 March, 2013 - No Comments!

The Rails Code

Here is a few stuff that, I wish I knew, or I forgot along the way when developing asknative’s API. Just know that I didn’t have any previous REST or Rails background before that, so keep that in mind while reading.

Code Structure

  1. Controllers. Its job is to take data from the request pass it to models, then pass leave it to views. So don’t put any thing more than that, not queries not JSON response messages.
  2. Models. Defines your documents(tables in SQL), relations, queries it, and other functions thats needed for the model or controllers. It’s like helpers for Controllers. Most of your coding will be here.
  3. Views. Can be HTML, or JSON. So never define put conditions there nor queries. Thats what are helpers for. Even if you just do simple user.count.
  4. Helpers. Used for handling simple and complex functions that is only needed for the views. If you need something outside views scope, define it in the model. Else go with helpers. This will make your code readable, more easy to change, and accessed by other views.
  5. Gems. Give you extra predefined functionalities without messing your code.

Controllers = Managers (They never do actual work)

First thing to know is to keep your controllers thin, and models fat. Controllers are supposed to connect, and thats it. It manages everyone, so don’t put extra work on it. Because if you did, it would really be hard read or change your code unless you do that.

Use before_filter in controllers to handle repetitive tasks like User.find(params[:id]), and make sure you define who will need this using only and except.

If you have something that takes parameters, and needed in all controllers like limit and skip, you can define it as a protected function in the ApplicationController so that it can be accessed and changed for all the application.

If there is a case that you still don’t want to create a function in the model that handles specific tasks in the model, then create a private function that will be called in your controllers. So that you still have a clean and readable code.

As a general rule, controllers should only call functions, and if conditions that call specific functions for each situation then pass it to views. I can’t stress this enough, but this is the most important place to be readable, when you look at it, you should know what goes where and to whom.

Models are Fat

Models are helpers of the controllers, if you need a query or a function, it should be there. You can use def self.query to use it like this User.query without having to define it first. Which comes in handy for listing queries. But incase you need something simple go with scopes, they are simple and more efficient.

Use model callbacks like after_save, and before_save to handle errands. If you want to notify the user when there is a new post, then put it in after_save method.

Gems are cool

Everyone talks about how bad gems are when you are getting started with Rails, I disagree. I think they are amazing, as they help you see how you can do things correctly. Because when getting started no matter what you do you will mess things up, so I believe don’t try to run before you can walk, don’t get ahead of yourself. Use gems, and when you become strong enough, you can create your own gems that are specifically tailored for you.

Respect for RSPEC

I’m guilty of being scared of testing. I thought it was hard, but it turned out to be a life saver. It is extremely easy, and will get out of your way. You don’t need to open the browser to test a case, and you can’t the whole application in the browser every time you want to deploy.

Whats awesome about testing is that you can test everything, without doing it yourself. You don’t have to remember all the cases which broke your code. You just have to write it down.

For me I started doing this lately, so I still write dump repetitive code, but it works great.

Use watchr while you are refactoring so that it makes sure that nothing breaks, and if it does, you can handle it quickly.

Before deploy just run your test, and save your self some embarrassment after you deploy and find a stupid issue.

If you like this post, stay tuned for mongoid tips post.

21 March, 2013 - No Comments!

Passwordless SSH to Ubuntu

I know this is a no brainer for most people, but it took me sometime to do it, so incase anyone having problems with connecting via SSH to Ubuntu here is a simple walkthrough.

  1. Create or Copy Development machine’s public RSA located ~/.ssh/id_rsa.pub
  2. Login to server and paste it in vim ~/.ssh/authorized_keys
  3. Ensure that /etc/ssh/sshd_config contains PubkeyAuthentication yes and RSAAuthentication yes uncommented
  4. Finally set chmod go-w ~/, chmod 700 ~/.ssh, and chmod 600 ~/.ssh/authorized_keys to make sure that permissions are set correctly


For more information check this guide
http://library.linode.com/securing-your-server . Thanks to @kamasheto