Archives for March 2013

March 30, 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.

March 21, 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

Update

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

March 20, 2013 - No Comments!

The Native Setup

I’m just a designer, but some stuff happened that resulted in me developing a whole REST API in Ruby on Rails. It was the first time for me to use Ruby but thanks to Rails community and Gems I learned fast and did something decent in no time.

Anyway I just want to share technologies we are currently using.

Server Setup

  • Ubuntu 12.04
  • Latest Nginx from Ubuntu
  • rbenv: To manage rubies for projects
  • Ruby 1.9.3
  • Rails 3.2.11
  • Redis: Used by Resque for background jobs

Rails Gems

  • Mongoid for mongodb
  • Devise for authentication and oAuth
  • RABL for formatting JSON responses
  • HTTParty for sending push notifications to pushbots
  • SendGrid for sending emails
  • Paperclip + for uploading attachments and sending them to Amazon S3
  • NewRelic for application monitoring
  • Mina for deployment, a lot smoother that Capistrano
  • Foreman for process management
  • Unicorn for running application server.
  • Resque for background jobs

Local Tips

  • Anvil. A utility for mac that allows you to drag any rails application and it will keep running and can be accessed via http://appName.dev
  • Genghis. An awesome tool for connecting to MongoDB. You can even set it up on the server to be accessed from any web browser.

March 17, 2013 - No Comments!

Mistakes of a Native

No matter what you read in books or others tell you, you will make mistakes in your startup, so accept it, learn from it and move on.

1. A Team of Founders

Never hire when you start. It should be always team of founders, 2-5 having 3 the perfect number for Design, Development, and Business. Hiring people to do your job is not the solution, because no matter what you do, they will still be employees, in their thinking and in their way of working. Going for a one man show is possible but don’t expect to release anytime soon.

2. Hire the Heart not the Brain

When hiring don’t choose the best developer for a group of interviewee’s hire the one who got the heart and passion for what they do, hire people who follow their heart, hire people who match your Startup culture and mindset. They are the people who will stay up all night for the release day, they are the people who are willing to give what it takes, they are the people who will not ask for tasks if they are free because they know what needs to be done.

3. Defined Hierarchy

Startups tend to be loose and friendly —which is cool. But without defining responsibilities and decision makers discussions will have no end. So be sure that you listen to others, explain your point, then take the decision or let the responsible one do it.

4. A Moving Platform

This one is critical, for a social network, never start with closed platform. I can’t stress this hard enough. When you target wide and broad set of people a closed platform will always require a set of other platforms. Here is a scenario “We are on iPhone”, “Do you have Android?”, “No”, “Windows”, “No”, “BB”, “No”, “Can you make one?”.

That is really annoying but its the truth, everyone will always want his platform, and hiring teams or freelancing to develop on all these platform and maintaining them requires a hell of a budget. So IMHO go for a JS web application with local storage from the start, unless you are relying on Apple or Google mobile API to do something cool or replying on the AppStore to advertise your application. You can always target specific mobile platform later.

5. Find your customer

Don’t look for the customer after you release or while testing, go look for the customer before you even start. He is the one who is going to pay, do don’t imagine the situation for him, go in forms, twitter, facebook and find out what annoys the user and what other competitors are doing wrong, then go do it better.

You can tailor a software for yourself, but you still need to find other customers like you with the same problems.

6. Never code without testing

Coding without testing is like climbing without a safe rope. Don’t expect your code to be working the same way after refactoring or adding a new feature. And relying on the tester to test all the cases he tested before is just bullshit. I’m not saying there should be no testers, but when discovering a flaw, it should not be able to make its way back to the application, and saying that its a waste of time or it will take more time, is more bullshit, because fixing bugs and re-fixing them will take more time from what you are trying to save.

7. Don’t sprint in an endurance race

The no sleep, no life, motivation speeches thing doesn’t work. In order to have a clear mind that is ready for work you need to stop the sprinting mentality with an endurance one. Go workout, have a good sleep, eat healthy, play from time to time, go watch a movie or a show, it’s not a wasted time, it’s what your mind needs in order to keep moving, and it will keep you from getting depressed. So keep your “all out” energy for times that you really need it.

8. Quality, Time, and Features

There is always sacrifice, and the best way to do it is to choose what are you willing to sacrifice. You can choose product quality with known cycles, but rolling features will be slow. You can choose definitive cycles and with lots of features, but quality will suffer. And finally you can choose quality and features, but take as long as you need or set a 3 months to 1 year period to make something perfect and polished.

It doesn’t matter what you choose as long as you know what you will sacrifice, and make peace with it.

9. Make some $$$

Don’t wait for enforcements to come, your alone in this shit hole, no one cares about your nor your startup, even if everyone likes the idea, doesn’t mean they are willing to share the risk with you. So the only way to deal with this is acting like there is no fund is coming, and find a way to make money before making your application. Show your worth before asking for money.

10. Launch

Launching is one of the hardes moments in your startup. It’s just a mixed feelings between fear and joy. You want to launch but scared that something will go wrong. So no matter what, launch first with little features, and no bugs, then add up as you go. By starting with less you will get feedback, be able to fix things fast, and know what features to add first.

Last words

When it comes to startups there is no definitive way of doing it, there is no recipe for success, so don’t regret any decisions you’ve done in the past. Past is only there to learn from, you can only become better when you learn from it.