Thumb marko Marko Ćilimković Monday, August 31, 2015

Web development can be a beautiful process. From an abstract point of view, it is no different than building a house, car or robot. It all starts from a piece of paper and a pen. You have a problem and you need to think of a solution, a solution that is going to solve the task effectively, correctly and in an acceptable timespan. Today there are a lot of design patterns that help us in setting the ground for that engineering process, but after the plannings, discussions and corrections are over you need to choose which tools and accessories you're gonna use in the implementation process.

Fast-paced World

From a developers perspective people today are undermining programming much more than they did 15 to 20 years ago. I guess it's because back then people didn't have so much access to all that knowledge and...they didn't HAVE a computer to begin with, so it was a mystery how all worked. Because of that you will run into clients that don't just tell you what they want, but also how and when they want you to do it.

If you're one of those developers that have a brilliant idea and they get filthy rich after the implementation because a big company bought their source code, good for you, but most of us are stuck with our loving clients that want the best, the fastest, the prettiest and of course the cheapest solution on the market. Thankfully, except for client requests, the technology is also growing each day and, therefore we can meet up with those deadlines.

Better, faster, stronger

A big asset to the successful delivery of our web projects is Ruby on Rails. We don't use the same CMS for each and every new project like most companies do with Wordpress. We create a new one from scratch! The benefit is having a custom system with no piled up old code from another project. It is tailored to suit all of the clients needs. It's faster and no unnecessary plugins choke the app's performance.

The downsides are - there are no downsides! You might think that starting a new project from scratch is a wild goose chase because too much time is spent on doing what mostly always needs to be implemented in a web application (authentication, authorization, multilingual support etc...) Rails's biggest friends are RubyGems which are basically plugins that can easily be installed and adjusted for your application so no major time loss is spent on doing that.

There isn't always a gem for every feature you need. In that case, you need to implement it by yourself, which is even better because developing in Rails is like talking to your computer. You need a new model that's going to contain everything a blog post needs?

rails generate model BlogPost title:string content:text picture:string author:references

After running this command in your terminal, a new migration file is created, which can be executed with

rake db:migrate

Done! You got yourself a brand new model, but more about the development process is going to be covered in my other blog posts.

Ch, ch, ch, changes

Have you ever sat down with someone and created a wonderful plan which you thought was flawless? You even started and finished coding everything and the project was ready for evaluation. after which everyone was happy and you got your paycheck? I honestly think that scenario is impossible. IF you're lucky you will have just a couple of alterations, but most of the time "nothing is how it's supposed to be".

The clock is ticking and the deadline is getting awfully close. What to do? Start from scratch or start changing the code? I remember a couple of years back when I was programming in Java EE a really complex, but carefully devised application. There was around 5 developers and we spent roughly 2 years on the project before we showed what we did to the customers. Sadly, they weren't satisfied at all with the workflow and the project was redirected to another team (how embarrassing), but now I feel good, because I know that we didn't make a mistake in the code, but in the tool we were using.

Maintenance misery

"Trust me, I'm an engineer" is a popular internet quote which is telling the public that engineers have a solution to every problem, but not all engineers have the same types of problems. One of those problems that developers have is maintenance. Web development is a delicate process that results with a project. After the project gets sold, its story doesn't end there. There are various reasons to it: the client is unsatisfied with the user experience, design, workflow, response times etc. But all of the possible reasons have one thing in common and that's going back to the code you wrote.

1. The Herd Instinct

I remember back in 2011 when I first started developing web applications and when I thought that I'm a developer when I knew HTML and CSS. Like most developers, the first real programming language I used was PHP. And not the fancy PHP that's using object-oriented programming, frameworks or PDO's (PHP Data Objects), but the procedural way of programming with the deprecated MySQL extension for connecting to a MySQL database. When I look back now there are some advantages to using PHP, but there are a lot more disadvantages.

Since PHP is a language designed specifically for web development its speed is the strongest argument. It beats every language in the number of HTTP requests it can take and the time to deliver each request. Great! You immediately stop reading this blog and you made your decision to start developing in PHP because you want the fastest application on the web.

There are several roadblocks you'll hit and I'll mention just my top ones. Since you're using raw PHP, you have to think of everything - architecture, security, modularity, optimisation and so on. This leaves you sitting ducks for potential cross-site scripting vulnerabilities and security issues.

2. Don't reinvent the wheel

The solution to this problem is to use a framework (or create your own) which deals with the majority of these problems automatically. But there is a drawback in this solution and that's...wait for it...speed! Popular PHP frameworks like Zend, or Laravel have similar results performance wise like other programming languages that use frameworks. But using frameworks doesn't solve one important issue and that's the ugliness of the code which is my most important misery of maintenance.

Just remember, every day you'll have to look at this type of code

$connection = mysql_connect("$host", "$username", "$password")
or die("cannot connect"); mysql_select_db("$db_name") or die("cannot select DB"); $collect_points = mysql_query("SELECT * FROM points WHERE (created_at BETWEEN '".$_SESSION['global_date_from']."' AND '".$_SESSION['global_date_to']."')");
while($niz2 = mysql_fetch_assoc($collect_points)) {
if($row['id'] == $niz2['member']) {
if($niz2['claimed'] == 1) {
$count += $niz2['points'];

$collect_given_points = mysql_query("SELECT t1.type AS typeWG, points.WG, points.created_at, points.member, points.savedBy, points.points, points.claimed
FROM points INNER JOIN WG AS t1 ON points.WG =
WHERE savedBy ='".$row['id']."'
AND member != '".$row['id']."'
AND claimed = '1'
AND (created_at BETWEEN '".$_SESSION['global_date_from']."' AND '".$_SESSION['global_date_to']."')");
while ($cgpResult = mysql_fetch_array($collect_given_points)) {
if ($cgpResult['typeWG'] == 'WORK_GROUP') {
$bonusPoints += round((30 / 100) * $cgpResult['points']);
$gaveWGPoints += $cgpResult['points'];
else {
$bonusPoints += round((10 / 100) * $cgpResult['points']);
$gaveProjectPoints += $cgpResult['points'];

$collect_esnet_points = mysql_query("SELECT present.*, AS 'MeetingDate', t2.naziv AS 'MeetingName'
FROM present INNER JOIN meetings
AS t2 ON");

You can notice the biggest problem here. The MySQL queries are embedded in the views, both with the business logic of the application. It's like having a relationship because he/she is rich, drives a fast car, is averagely clever, but every night you need to go to bed thinking: "Why am I doing this to myself?".

3. MVC

One of the beauties in Ruby on Rails is that it's using the MVC architectural pattern. The models contain the business logic and the soul of the application, the views represent all information to the end user and the controller is the glue between the two. Here's a nicely structured model that contains the brains of all places in an application.

app/models/place.rbclass Place < ActiveRecord::Base
include Tagging include Suggestable #Associations has_and_belongs_to_many :clients #Validations validates_presence_of :name, :latitude, :longitude, :picture validates_numericality_of :latitude, :longitude #ClassMethods def includes(:tags).where("lower( = ?", query.safe_downcase) end end

Where are all the other methods needed for connecting to a database, data table? Where are the create, read, update, delete methods you ask? Well, Rails handles that automagically and keeps it away, extracted from the developer so he can focus on the main task of the application and ignore all the nitty gritty details.

Unknown grounds

Have you ever had that feeling that you're not good enough in what you do? That you didn't come up with something so simple and logical, or that you just didn't know an answer to a question? You think that one developer is better than you? Me too! And guess what, a lot of other people feel the same way. It's called the Impostor syndrome and I read an awesome blog that I could relate to in almost every sentence.

The fact about it is that's it's perfectly normal to feel that way and that a lot of other people feel the same. It's ok to make mistakes and it's not bad if you don't know everything! And if you ever feel that way and you don't know how to solve a hard task or you think you're doing it in a bad way and it could backfire in the future, remember that you're not alone. By that, I think of the community behind a tool you're using to achieve the wanted results. I cannot describe how important the community is in those kinds of situations. Imagine spending hours, days, weeks, trying to implement a new feature in your web application, but something just doesn't want to work. Google is your friend, and a lot of people use Google, so you need to make sure you're not using some ancient or fairly unknown programming language/framework in order to find a solution to your problem.

Sometimes you want to go

where everybody knows your name :)

Ruby on Rails has a wonderful community where you can subscribe on various mailing lists, listen to podcasts that keep you up to date with the news in the Ruby world and ask for help when you're all alone in the code jungle.

Itsy bitsy bug

 If you're suffering from insectophobia, don't stop reading this section! No bugs are to be found in this blog :)

A bug is, as you might know, a common "feature" that occurs in software applications that the owner (developer) wasn't aware of until the user acknowledged him of it. A bug in your code is a result of implementing something fast when you didn't think all things through, or you didn't understand the workflow, or you just mistyped a value or variable name. Either way, a bug will result in an output like this

 Servlet]: PWC1406: Servlet.service() for servlet Faces Servlet threw
 org.jboss.weld.context.NonexistentConversationException: WELD-000321 No
 conversation found to restore for id 1
         at com.sun.faces.lifecycle.Phase.handleBeforePhase(
         at com.sun.faces.lifecycle.Phase.doPhase(

Can you figure out what the hell went wrong here? Neither can I! This is a bug from a live application written in Java EE that thousands of people are using today, but the silver lining is the it's not occurring so often so I used the Ostrich Algorithm and ignored it. Things would be so much easier to debug if the error message was more concise, right?

You guessed it! Rails prints out errors really nicely. Here's a couple of them

Couldn't find BlogPost with 'id'=404
No route matches [GET] "/blog/404/save"
Missing partial post/questions, application/questions with {:locale=>[:en], :formats=>[:html], :handlers=>[:erb, :builder, :coffee]}. Searched in:* "/Users/..../<project name>/app/views"

If you're a developer you will probably know where to look in order to debug these error messages. The key argument here is that they are not riddled! They help the developer by actually telling him where to look and what to look for.

Rails - Killer App for Ruby 

And lastly, for those who were skimming through the content of this blog post, here's a summary why you should use Ruby on Rails:

  1. encourages agile development - large and complex features are fun to implement and take less time
  2. simplifies changes - major implementation changes are not that abstract and major anymore
  3. maintenance is not a drag - don't feel bad if you need to revisit your old code
  4. large community - no need to feel lost, other developers will help you
  5. beautiful syntax - no need to clarify this statement :)

Ruby on Rails is an open-source web framework that’s optimized for programmer happiness and sustainable productivity. It lets you write beautiful code by favoring convention over configuration.

Starting a new chapter in life is difficult! Heck, even choosing the right character in Skyrim is the hardest part of the game. It's the same in choosing the right programming language and/or web framework. Just bare in mind that nothing is perfect and that whatever you choose you'll end up hitting a roadblock or two. It's the decision at the beginning that orchestrates the time you'll spend on removing the roadblock :)

Happy hacking!

Cookies help us deliver our services. By using our services, you agree to our use of cookies.