Friday, September 26, 2014

Content-heavy sites, choosing between Ruby-on-Rails and PHP

"Easy training, hard battle. Hard training, easy battle!" -- http://www.leonardteo.com/2012/07/ruby-on-rails-vs-php-the-good-the-bad/


While reading Leonard Teo's article on when to choose Ruby-on-Rails or PHP, reading the first few paragraphs I wanted to learn RoR, then on next few paragraphs I'm leaning towards to learn PHP again, then on the middle paragraphs it seems like learning RoR is a wiser choice, but then on the last few paragraphs it felt to me PHP is not that bad; and then when while reading the comments, I'm gravitating again towards RoR, oh well.. :-) It took some six swings when choosing between RoR vs PHP while reading the article up to the last comment


Can't blame me :-) The article was written in 2012 and then updated this year and there are many insightful comments on that article too, having read the entire article and comments, it looks like there is now a renaissance on PHP. There are now new PHP frameworks which doesn't carry the crufts of the older PHP versions and only the language's latest capabilities are applied to new frameworks, making those newer frameworks cleaner and developer-friendly. A PHP MVC framework like Laravel is such an example



I tweeted:

RoR is a mature framework now, it's boring: http://www.leonardteo.com/2012/07/ruby-on-rails-vs-php-the-good-the-bad/

RT @nguerrera Great code is often boring. Exciting code is often wrong.



While RoR is mature now, I'm gravitating towards Laravel; not because it is exciting, but that helps too :-) I used PHP for about half a year on my first job a long time ago, so I'm new to PHP MVC frameworks now. The insightful thoughts from Pierre sealed the deal for me:

As others have suggested here you really should look at Laravel. The frameworks you mention (with the exception o possibly symphony) are what I would call "legacy" frameworks. They all have a long history going back to PHP 4 and are burdened by that legacy.

Laravel lacks that. The author of the framework was not a PHP developer originally. He came from a .NET/Ruby background and arrived on the scene only a few years ago. As such he started by supporting php 5.3 and didn't bother with legacy support.

So Laravel has some of the best features from Rails and .NET baked in: ORM, Active Records, robust routing, generators, migrations, BLADE (think Razor in .NET) etc.... In addition serious PHP frameworks now use Composer for all their components and most of their core. Just like Ruby Gems and Node's packages everything is centralized and not coupled to a particular framework. So you're only updating components via composer using the command line and not your entire framework. (Symphony is using this method as well)

In short, PHP has grown up in some respects. Laravel really is the closest thing PHP has to Rails, if you want to compare something closer in scope have a look at it.



With the author of Laravel experience in ASP.NET MVC, I'm curious to learn how much of the good ideas in ASP.NET MVC are injected into Laravel


So why not just adopt ASP.NET MVC for content-heavy sites since I have experience with ASP.NET MVC too? PHP is ubiquitous, cloud choices is definitely a plus. Microsoft having decided Windows on Azure should carry a premium price tag, Linux on Azure is budget-friendly



As compared to Ruby-on-Rails, Laravel has the controllers done right. See: http://lostechies.com/derickbailey/2014/01/30/playing-with-laravel-4-the-php-mvc-framework-and-telerik-ui/



And how about Java MVC frameworks? You can forgot Java when your server's resources is limited



Happy Coding!

AngularJS bind once musing

After reading this: http://angular-tips.com/blog/2013/08/removing-the-unneeded-watches/


I'm somehow convinced it's better to do the localization during logon only. So bindings on localizations on labels, titles, etc could be done once only


Other good sources on keeping the quantity of $watches low:
http://angular-tips.com/blog/2013/08/watch-how-the-apply-runs-a-digest/
http://www.benlesh.com/2013/10/title.html

Tuesday, September 9, 2014

Thoughts On Best Practices

OH: “Do programmers have any specific superstitions?”

“Yeah, but we call them best practices.”

-- David Grandinetti




Good read on best practices:

"It has a chilling effect on our progress as an intellectual craft when people pretend that a best practice exists" -- James Bach

"Rather than simply stating what we've done and how we did it, we feel compelled to puff it up into a spiny, intimidating best practice. We attach our egos to our code frameworks. If someone doesn't agree with our approach, they're attacking us personally. If someone has a different best practice, they're amateurs who don't understand the problem domain" -- Jeff Atwood




My aversion on best practices, everyone has their own beliefs, it follows that everyone has their own notion of best practice


There's really no one best practice, everyone has one; or should we just take it the easy way and just find like-minded folks who share our notion of best practice? It's not good to find folks who'll just reinforce same beliefs, things are a lot better and interesting when we find others who can find loopholes or provide constructive criticism on things we believe are right



Lastly, most of the time, I find that people who tend to ask a best practice question can be classified in two types, either they are lazy and wanted to be spoonfed or an askhole



Believing our practice is the best practice, tends to make us crap on other people's choice and enthusiasm, and it's not good



Better not to believe there's a best practice at all especially if we will just use it on intimidating other people



Happy Coding!

Thursday, August 21, 2014

When using jQuery, let its API do the heavy lifting

Instead of this:

var particles = $('.particle');
$('li').each(function() {
    if (!$(this).is(particles))
        $(this).css('color','red');
});    



Do this:
var particles = $('.particle');
$('li').not(particles).css('color','red')

Thursday, July 24, 2014

On TypeScript, the this keyword doesn't always reference the instance of a class

///<reference path='jquery.d.ts' />

class Mate {
    public n : number;

    public name : string = "Freddie";

    public nick : string = "Fred";



    public message() : void {

        var people = new Array<Person>();



        {
            var p = new Person();
            p.name = "Ely";
            people.push(p);
        }

        {
            var p = new Person();
            p.name = "Raymund";
            people.push(p);
        }




        $.each(people, function() {
            alert('inline: ' + this.name + ' -- ' + this.nick);
        });
        /*
        Outputs:
        inline: Ely -- undefined
        inline: Raymund -- undefined
        */


        $.each(people, this.alerter);
        /*
        Coming from traditional OOP, I expected:
        Freddie -- Fred
        Freddie -- Fred

        What happens:
        Ely -- undefined
        Raymund -- undefined
        */



        $.each(people, () => alert('inline: ' + this.name + ' -- ' + this.nick) );
        /*
        Outputs:
        inline: Freddie -- Fred
        inline: Freddie -- Fred
        */


        $.each(people, () => this.alerter());
        /*
        Outputs:
        Freddie -- Fred
        Freddie -- Fred
        */


    }

    public alerter() : void {
        alert(this.name + ' -- ' + this.nick);

    }

}

class Person {
    public name : string;
}


$(function() {
    var m = new Mate();
    m.message();
});

Thursday, May 15, 2014

JavaScript Technologies

Technologies don't know how to fight, and what's more, some of them even complement each other

Tuesday, May 6, 2014

PostgreSQL (mis)feature

Martin Smith pointed out a gotcha on Postgres feature I recommended


GROUP BY on alias doesn't work properly when the alias has a same name from the table's columns

select 'foo' as Table_name
from information_schema.tables 
group by Table_name


Live code: http://sqlfiddle.com/#!15/d41d8/1920