Posts Tagged "kohana"

Opinions: Be a Developer… Part III

Posted by David on Nov 14, 2011 in Articles, Opinions | 0 comments

Time and Cost in Favor Of Security

Posted by David on Sep 26, 2011 in Articles, Opinions | 0 comments

Beginners dilemma: do it properly and actually learn something new or do it so it gets done fast. Never mind the flexibility, security and the feelings of future developers as long as the task at hand gets done with minimal time consumption and makes one look like a pro, for the moment.

That kind of attitude reminds me a mix of The Office and The Simpsons. Yes – you can hack together something that barely manages to fulfill the current requirements… but then someone exploits the broken system or it collapses because a change in the environment or another developer has to do it over again, maybe from his own spare time because the business side can’t justify the time spent on refactoring a kind-of working system.

I’m in full agreement that we (the developers) can’t follow the golden rules all the time in the real world and compromises must be made to lower the costs… and then I wonder what the clients would say if the company told them point-blank from where the money is/was saved. The fact that the developers think the website/app will never be under any sort of attack, trust the user to input the right kind of data or guard their cookies is naive.

A situation like that is even more passionate when the team is split: one of the developers believes and is willing to do extra work to have some confidence in his creation, the other just does like it’s always been done.

A Real-world Example

Imagine now that you had to set up a WYSIWYG editor with file upload capability – like CKEditor. CKEditor has 2 crucial parts for the server-side. One is the config file, the other the actual (PHP) uploader script. Below is a section of the config.php file.

/**
 * This function must check the user session to be sure that he/she is
 * authorized to upload and access files in the File Browser.
 *
 * @return boolean
 */
function CheckAuthentication()
{
    // WARNING : DO NOT simply return "true". By doing so, you are allowing
    // "anyone" to upload and list the files in your server. You must implement
    // some kind of session validation here. Even something very simple as...

    // return isset($_SESSION['IsAuthorized']) && $_SESSION['IsAuthorized'];

    // ... where $_SESSION['IsAuthorized'] is set to "true" as soon as the
    // user logs in your system. To be able to use session variables don't
    // forget to add session_start() at the top of this file.

    return false;

}

As you can see, CKEdit doesn’t really do anything until true is returned from the CheckAuthentication() function. It’s really tempting to do just that and skip the whole auth-thing to win those crucial minutes. The red (figuratively) warnings above don’t really mean anything because surely, who’d ever want to attack our site OR who’d ever think to exploit the file upload script? We have one login page in front of the uploading script anyway.

Yeah. So what really happens is that the user doesn’t notice anything unless (s)he has some technical knowledge and knows what to look for: an unprotected HTML page that accepts POST data. You’ve solved the current situation and don’t want to go back to deal with the problem. The customer is (wrongly) happy and you get paid.

You should never neglect the most basic security to win time – not on anything that eventually ends up in production. The problem above would be solved by including the framework/code that manages the main site and calling the auth check function. On Kohana 3 it would look like this:

define('SUPPRESS_REQUEST', TRUE);
require('../../index.php');
return Auth::instance()->logged_in();

Done! Problem solved. Did it really take that long? Assuming you knew something about Kohana and it’s modules.

If no-one specifically forbids you from thinking about security, do think about it. If you’re not allowed to write code you’re confident in, tell the managers they get what they pay for or find a new job.

Opinions: Be a Developer… Part II

Posted by David on Sep 8, 2011 in Articles, Opinions | 3 comments

?This is a continuation of the previous post, "Opinions: Be a Developer, Not a Programmer Part I".

Ando Roots

It's true that teachers always try to teach things as they should be… at least the good ones. That's because, as with every learning, we learn things in details that later wear off. If we're told to use design pattern X then there's hope that as years go by, we fall back to design pattern M instead of all the way to A. Also consider that most professors work in the field they teach so they know of the 'real world'… at least in my applied sciences college.

Even though I haven't done any real agile development before, I don't think it’s "extremely slow" because in it's heart, Scrum (as an example) is made up of iterations that allow the team quick feedback and the customer control over what to change in the next iteration. So if Twitter invents video chat and FB uses SCRUM, there's hope Facebook's own feature will be out the next week.

There are no developers who don't test their own code (or they aren't developers). Any real testing however involves writing automated test cases. Which is notoriously difficult when you work with a person who thinks it's pointless and a waste of time and breaks (my) tests constantly by modifying the code, but not the tests. Do I even dare to dream of version control when "cp folder1 folder2" suffices?

?Framework restrictions

There ARE restrictive frameworks out there. Some might find the rules comfortable since then it doesn't matter whose code you write/modify – you know exactly where to look for something and even if you happen upon an undocumented piece of code, you have a general idea of what's it for.

On the other hand, there are frameworks that implement a general structure such as how controllers/models are structured and then leave the rest up to you. You can and are encouraged to use the particular conventions of the framework, but you may also deviate and create your own rules. It's the same as with laws: you don't like Estonian, go east – maybe it's just right for your style. In general however, you wouldn't ever want to go all the way to the North Pole where there are no (maybe an exaggeration) rules whatsoever – rules such as "thou shall not kill" make life easier.

I approve of the style of using classes and libraries because that strips away the need to invent a triangular wheel…but on the other hand, doesn't give (for granted) you the separation and all other goodies a truer HMVC approach does.

My boss and I have long argued over placing functions in classes, his argument being that loading classes takes far more memory than including a function collection. I've never proven it, but my train of thought is that if the rest of the world – including some opinion leaders – do it and succeed in earning their monthly paycheck, it's the way to go.

What is more, computing power on small-to-medium scale web applications is not an issue anymore. I can allow for some more MB-s of memory on scalable hosting such as the Amazon cloud or Google's own Appengine. And, speaking of the real world again from an (local) Estonian company perspective, most developed application never get such an amount of traffic/usage that the issue of critical resource depletion comes up.

?Convention over Configuration

I disagree with you on the point that complicated tasks should be simplified instead of the simple/common ones. It's far more difficult to guess the particular needs of a complicated task, thus creating the restrictive rules you mentioned. Think for a second: what are the two most common actions a web application does?

Nope, think some more…

Yes! The answer is user auth (signup/login) and CRUD. If I have Kohana with it's Auth and Formo modules, I can present the user with a working prototype of a password protected memo/tweet/warehouse system within the span of half an hour – that I quite possibly whipped up while (s)he was still going over the details with the company salesman.

With Frameworks, this kind of a task is trivial. With libraries, it's not: you have to write some code (don't forget your validations!) and HTML forms, instead of creating the database and routing info and leaving the rest up to Convention over Configuration. That's great for prototyping, but also during and after the main development. Adding a new field is as simple as creating the database field and specifying validation rules.

It's important to go for speed from the start if you're building the next Twitter. It doesn't matter if you're doing a custom-built app for a company of 100 employees. This may be another trap for the impatient ones, too. The client wants results and fast. If none are given, well, there are always other willing parties, especially if you don't do Waterfall, where the contract is "signed with blood" ( – P. Leis).

A word in favor of ditching frameworks tough: you are right that if you indeed work at NASA, you DO reinvent the space shuttle, just so you could have the absolute and total knowledge and control.

?To use a framework…

Frameworks are equally important when you're building a front-end for other services, in fact I'd say that's a case where you’d want to use a Framework even more. Why? If you're not doing any complex calculations on the same machine, you have free memory; memory that the framework can use and justify it's existence. I'd say you should pass on the framework when you're building an API. THEN you need all the juice you can get since API-s usually have far bigger loads.

Speaking of reality (yeah, but we must)… You'd want to use a framework by default, unless special requirements – huge load, knowledge of the future, framework restrictions – point you the other way. You want to develop fast and present the client with a prototype early, so you can get feedback faster, so you can ship a better product. To do that, you use a framework so you don't have to tell the boss that you wrote HTML forms and created validations in the form of a series of if statements for the whole 1st day. You'd also do things the Agile way to adopt to changes fast. And when that doesn't work out, you can always Kanban and be done with it.

And no, I wouldn't stamp a developer bad just because he's not fast enough. I've seen no scalar attribute by which to grade a developer, with the exception of WTF / minute… and the opinions of developers who have to maintain the other's code in the future.

?Development – a Creative Process ?

Now comes the part I dread to write, because your last point is the one I disagree with most strongly.

Writing software IS (with double underlining) a creative process. [big fat period] It's the typical way of thinking for functional programmers who look at the world like this:

Okay, to solve this problem, I write function X and I can see that function X needs function Y and so I write function Y. Clearly, function Y must calculate the tax return so I have to look up the percentages and just code the function to return the value Z. I don't really fancy writing function Y because I don't like rinse-and-repeat, but I have to do this so I could do the same with function X.

I'm clearly exaggerating again, but without personal experience, my opinion stands.

On the other hand, I'm like this:

Hmm…what an interesting problem! I already see three possible solutions for it. What if I asked the framework to do the calculations for X? Hmm, no, that would expose vulnerability A so I don't do that. What about using an external API? Ahh, damn, that could work for a short while, but I know for a fact the company is going to need B on the next month so I better do this right. Oh! But really, the problem boils down to calculating the tax return rate and I can do this easily by implementing Z! Okay, so it will take 5 minutes longer, but the return value will be far greater than doing X or Y.

Another exaggeration. But the point is that by thinking things over, by being aware of conventions, of what's happening out there, experimenting and, most importantly, using your own head to seek for solutions – not just going by the book with the rinse-and-repeat method – is so much more than writing software following the user manual or the only “right” way.

Think of the life of a small town physics professor and his colleague at MIT. They do the exact same thing, but one of them takes and gives far more to the job.

Code or programming in itself might not be creative in the strict sense of the word, but neither is a blank canvas. It's the idea of the artist that matters. Innovation born of experimentation is what thrives us forward. If you take the act of coding as a mundane task that can never offer you such self-satisfaction as say for an example, an architect seeing his building come to life… what good are you to the society as a whole? I could only see myself as a depressed person forced to write character after character, day after day. None of that when I have the creative freedom to dream up solutions. Then you'll see an excited geek hammering away at the keyboard.

I'll take your quote

Software serves creative needs, development it's not creative itself, it's just functional.

- K. Vaher

and use it. So when some of my fellow Developers cross me, I'll tell them to shut it, because they're "just functional", like a cogwheel in a big machine called the World.

?Parting words

It's a passionate topic of discussion. I tried to argument my reasons as best as I could and if it appeared that I only ever argued for the sake of arguing – it's not so.

There are merits in using no frameworks, there are compromises to be made between idealism and getting things done. Different people have different understandings of what's good and why – and it should be so for if there were no disagreement, we'd be a hive.

Thank you for being a worthy opponent on the bloody arena of one of the most violent wars since Linux vs. Windows.

Kristo Vaher

Alright, for starters, frameworks vs no frameworks is not the bloodiest war since Linux vs Windows. It really is not. I absolutely love web development frameworks. I both like the heavy-handed things like Zend, which I studied when I was a young developer because everybody said it was 'the thing'. I later on loved the speed of Codeigniter and then Kohana, which I think is by far the best framework for website development out there. And I love WordPress since even a beginner can set up quality website with custom needs there with little problems without sacrificing potential.

Creativity Before Coding

But writing code is not a creative process. You misunderstood my point there. You should never write code out of thin air. You need to have the idea of the system and its components already in your head before writing first lines of code. You should know what is the workflow of registration system, what needs the client has and what the end system has to be able to do while at the same time staying within development budget, which is very restricted in majority of projects I've taken part of.

The creative process of software development happens before writing a single line of code. Being able to write beautiful functions and classes or having source code that looks so pretty that you'd want to make babies with it is not the goal. A developer has a duty to realize the development plan as well as possible, but 'writing code' itself is not creative. You can solve the same problem multiple ways and since the end user is unable to tell the difference, it's not a creative process since it does not benefit from being one.

This is the big difference between a software developer and a programmer. Most of the developers that have gone through in my company have been just programmers. They are not creative, they are functional. They know how to solve problems or build modules and they are working on something that has already been designed. Some programmers dabble more into designing the whole system and paying attention to usability, but it is rare. Those that do, dabble into software design, which is indeed a creative process.

?Development in Reality

As for agile development, let's speak again in a few years time when you've tried to implement it in a small company in numerous client projects without wanting to blow your brains out with a shotgun loaded with dynamite. In the end of the day it is all about the budget and agile development costs more time and money 90% of the time. There are projects where this is possible, but very few companies are willing to invest in it and even fewer clients are willing to pay for it. You have to compromise. If you have to test out and confirm every feature as it's being implemented you either have to do multiple projects at the same time or just have a client who is willing to pay a lot of money, which is very rare in Estonia in current economy.

I totally agree with your idealized vision of software development, but it is vision of software evangelists. In reality it is just not possible. There's not a single system developed that has not compromised bigtime. Facebook is being refactored even today and it is very slow to release features. Twitter refactored large parts of itself last year and is – in general – a really simplistic system. Even Google is known for refactoring (and sometimes breaking) even its own systems and they are known for writing some of the most 'beautiful' code out there. Hacks are nature of software development since getting the feature out in working condition is more important than how good it looks inside. And all of those systems share one very important need for well defined and documented API.

This returns to the point of if you are making something large, you have to design it without putting much weight on frameworks unless you are able to completely strip it to its bones and only use the essentials that are not hindrance on the end product. In general, if you begin designing something that might have thousands of active users at the same time, you really have to start from the clean sheet and then speed up the process of development by refactoring classes and methods from your pre-existing libraries. It's not the framework that developer uses that makes them valuable, but the tools they have gathered over the years. In my own example, I have an external encrypted hard drive that contains hundreds of code examples, classes and open source packages for any need that might arise without needing me to implement an entire framework.

Speed and computing power is of critical importance no matter how much computing power you have available. Worst thing that can happen to a system is to become popular and not be able to keep things running. Facebook won the battle of social networking because it implemented gradual releases in different parts of America and then later on in the world, while the big competitor Friendster attempted to bite too much at the same time and suffered with downtimes and slow service. Twitter would never have become what it is today had it suddenly developed problems with performance. While it is true that just buying more computing power could solve that problem, with large systems a more optimized and lean code can save a lot of money.

When to Use What

And since API's (which are a must for any public system that isn't just a website or e-shop these days) benefit strongly from being just as lean, frameworks just are not good enough.

And people speaking of MVC or other software development patterns in a way as if they need a framework to be implemented perhaps have not designed MVC system themselves, because the concept behind MVC is relatively simple and can be set up by less than couple hundred lines of code with all the basics a system might need.

I strongly recommend frameworks for developing websites and e-shops and simpler info systems and I most certainly recommend studying how frameworks function since that may give better insight into MVC and other patterns than tutorials. But if speed is important you are better off implementing refactored functions and classes and build the system from ground up.

As a sidenote, in Apple vs Android battles this is also very evident. While Android is a much more flexible system than iOS, iOS implements better native code simply because of being written in Objective-C. iOS app's are simply more smooth and faster. Java is also compiled, but it is quite bloated (and there's a reason why Java frameworks are really not that well known), if not the most bloated system out there.

Parting Thoughts

So, to summarize.. There are compromises to both sides, but the choice of going one way or another should depend entirely on the project. Of course once that decision is made, the entire team should work in unison and if project implements a framework, its standards should be followed by the entire team.

There is no right or wrong answer, but I know that if I am given a choice between two systems that are functionally exactly the same, I will prefer the faster one.

Still more to come…

A good way to spend the weekend – Garage48 Tartu 2011

Posted by David on Aug 29, 2011 in Coding, Personal | 1 comment

Intro

Just Grab It

Mobile app that allows you to scan products and add if you like or dislike them. With the Just Grab It application you can easily organize your items to remember and recommend later.     

• URL: http://justgrab.it/
• Facebook: http://www.facebook.com/Justgrabit    
• Twitter: http://twitter.com/justgrabitapp    
• Team: Lauri Saidla, Martin Kangur, Margus Pala, Ando Roots, Esko Felin, Jaanus Jagomägi, Zahhar Kirillov, Mehis Pärn
   

This year's second #hackathon took place in Tartu University Faculty of Mathematics and Computer Science. As usual the teams were locked in a building (some more than others) for 48 hours and a weekend to try changing the world with the help of an overflow of Red Bull and snacks to go with it.

I'd hereby like to give some constructive criticism to those who feel they need it. These are my notes from during the initial pitching:

Pitching

• Do NOT turn your back to the audience to look at the slides. If you need to point at something, do it from the side. The slides are for the listeners to grab the key points of your talk. If you can't help yourself, use no slides at all or a static representative picture.

   

• Turning your back in effect loses your connection with the audience thereby decreasing any credibility you might have gained with your pitch. I joined a theater troupe and they made me quickly lose the bad habit. Again, this is important – don't stand with your back to the audience.

• Since we're already on the topic – a lot, and I mean A LOT of pitchers had a whole essay written on the slide up to a point where I though I was presented with an scientific article. The slide is meant as a supportive asset to back up your words, not the other way around. Thereby the reason for the repeating questions from the jury/audience: "…but what does it actually DO?"

  One of the best ppt-s I've seen in my life had just one to five words on a plain background written on each slide and the charismatic speaker used them as slides are meant to be used. Less is more. Look to Google for inspiration.

  This is my biggest rant about the weekend. I understand there were practice pitches earlier. Clearly they weren't through enough or the presenters themselves are to blame. The speakers in Helsinki (October) – use the constructive criticism. Also, since I got an inkling that I'd like to pitch myself soon too – use these words against me when the time comes.
   

• It was a shame to see a pitcher talking to the floor. I understand uncertainty better than most, but you have to make eye contact with your listeners – the people you're convincing to trust and invest in your idea.

• Be concise. 90 seconds is not a lot of time and as with the limited number of slides your words have to carry. To use fillers and tons of text is to kill the otherwise solid idea. Dead. Gone.

• Every single person who made the pitch – especially those not on the field of IT – deserves credit for their courage. So when it's actually your turn, I dearly wish you thought of something to say – not be forced to admit after 1/2 of the allocated time: "…that's basically it". If you're scared, start with a joke or two. Or let the slide do it for you in a subtle manner.

• Scary big auditorium. Lots and lots of people. Mic there for a reason.

There. Got it out of my system.

Friday: Day #1

The forming of teams in the style unique to G48 went… well, in the end everyone had teams. For a long time I had no idea which project to join, but then an interesting challenge popped up and I went for it. As always, some teams were at maximum capacity, some were disbanded, but every idea that deserved to live got it's chance.

There were 8 of us: team JustGrabIt – 2 designers, 2 back-end, a marketer, a visionary/project leader, an Android developer and a cross-functional do-it-all, hack-it-all IT guru. A full team. The idea itself can best be explained by it's website, but basically it's am Android slash web application for FB style (I do hope they didn't coin the term) like/dislike of real world objects.

The first evening ended about 2 in the morning with Kohana (more about my love for it: That’s how easy it is to create Twitter with Kohana 3) and the environment set up, some of the MVC files written – basically being ready to fire at the task ahead at full speed. We used GIThub for VCS and I was unhappy to see yet another person struggle to install it (and Apache2) on The WB OS (World's Best Operating System).

Sleep awaited on the hard floor of the lecture hall upstairs. I love G48 for leaving the venue open for (24 + 24)h. As expected, Zzzz… was one of the commodities not easily found as opposed to food and coffee which were always plentiful. I think we all suffered a minor case of sleep deprivation, but I'm totally fine with it.

Saturday: Day #2

Fast-Forward the next day: Early awakening, coffee and coding. And coding. Basically,

for (;;) code();

Our team was so big, we had 3 'departments': back-end, mobile, marketing. Communication wasn't an issue with a project manager in charge and I was only too eager (maybe a bit too so) to take the reins on the architectural level.

My programming buddy had a background of Ruby and PHP so we got along fine (is it true that Java and PHP fightalot?). Here's an interesting thought: even though he's teaching programming as a professor, even he couldn't crack Facebook login – but not for the lack of trying. I've chatted with and heard other developers complain about the same fact. It's like being in Quirks Mode all over again.

One of the good things that came out of the weekend was the new experience I gained with building API-s. Now I've been on both sides: the user (front-end developer) and the designer and realized I like the role that gets less comments and more complaints from the end-user better.

I'm regretful that I didn't use TDD. I know it's prototyping and all and we are supposed to YAGNI, but I'd still have liked to have at least a minimum amount of certainty in my code. Only one thing standing in the way: Kohana's (or rather, PHPUnit's) inability to make database driven application testing understandable and easy.

I've tried to follow Sebastian Bergmann's tutorial, but quite frankly, it's confusing as hell, forcing me to deal with XML and god knows what. If only there were such a thing for Kohana + PUnit like YAML database setup-teardown…

The lack of tests got me in trouble, ultimately resulting in an error being said (at least we commented out such debug messages like 'you suck') during the live demo. Still, I'm pleased with the work I did and plan to smooth it over when (not planning to leave another project hanging) I have the time.

Stayed up late (late for programmers usually means ~4am) with The Guru, trying to track down an image upload error. Did you know that you can capture and upload images from Android to an API as a base64 decoded string? Did some more work the next day and finally, just before the demo, wrote some JavaScript for a change.

Sunday: Day #3

There's always a frustrating bug in the code you get over and think that's the biggest obstacle but then come the frantic moments as the clock ticks mercilessly down and you silently say "FUCK!", get out your earplugs and dive into it. Which, by my careful observation of at least three designers is exactly the way to go to be productive.

Good design is very important in selling your idea. The implemented solutions ranged from no design at all (well, the bare minimum) to some really beautiful stuff, but in the end it's about delivering the functionality without sacrificing usability nor repelling users by not having something for the eye to rest on. Claim: everyone appreciates art in some form or the other, be it classical music or GUI button design. Compliments to both of our designers who not only knew what they were doing but weren't afraid to write the needed template code themselves to implement it when the main coders were otherwise occupied.

It's amazing what you can accomplish with 48 hours of self-sacrifice and dedication towards a common goal. The finished (or pieced together just for the demo) apps were up to the challenge and in my subjective opinion, three-four of them stand a real chance of starting something awesome.

Our team didn't win any prices, but that's okay. Often, it's not about the goal after all… and when projects die or are murdered, successful social ties remain… and good implementations rise to prove themselves.

Wrap

Garage48 was what I expected it to be – a draining weekend of fun and professional challenges coupled with learning. Eye-opening perspectives from the mentors were appreciated, good-natured mockery equally so. I hereby state that the organizers are awesome and deserve my respect as long as they have it within themselves to continue what they do… and a bit longer.

G48 is a wonderful chance for anyone with an idea – not just IT people – to come forth and give it a shot. If the outcome isn't what expected, you've learned something. If the project soars… who knows – maybe you're the next Rovio and just shake it.

Inspire. Teamwork. Solve. Conquer.

Relevant links

Garage48 Tartu 2011 Projects Launched

Garage48 Tartus: arendamisel on 14 projekti!

Qminder Wins Garage48 Tartu

Garage48 Tartu võitis Qminder

Garage48 võistluse võitja aitab lühendada järjekordi

That’s how easy it is to create Twitter with Kohana 3

Posted by David on Aug 25, 2011 in Coding, PHP | 0 comments

As Steve Krug would call it, some "happy talk"

Kohana has become my PHP framework of choice ever since I was forced to start using it about 9 months ago. Derived from CodeIgniter (interestingly enough I can't confirm that since, once again, Kohana's Wikipedia page has been deleted), Kohana has made several advancements and is now a fully capable framework I've come to love.

This article shows one of the reasons for that, namely how quick, easy and (arguably) elegant it is to create a web app from scratch using Kohana. The app we'll build is an extremely basic one, but coding it from scratch, without a framework… I don't even want to imagine.

The post is in the form of a tutorial and I'll write as if giving instructions to You.

Project Summary

We'll be building a very basic Twitter-type microblog application. The main functionalities of the site include:

• Login
• Making a micro-post (ie tweeting)
• Viewing a list of past micro-posts
• Deleting a post
• Logging out

We'll use Twitter's own Bootstrap toolkit (hey, what the heck, we're stealing their bread anyhow, why not in guns blazing?) that does all the heavy lifting on the CSS / design part. We won't be using any Javascript since that would be a post on it's own.

Setting it all up

[To be written, as soon as I have the time]

Coding

[To be written, as soon as I have the time]

Conclusion

Now that you've spent some hours (it took me 3 hours to write the fully-working code you see @ github) building the app, all you need to do is hire some marketing people and travel back in time 8-or-so years – the riches await.

Related articles

• Kohana 3.2 Validation Estonian translation (sqroot.eu)
• Twitter Releases Bootstrap, A Set Of Tools To Build Web Apps Using CSS (techcrunch.com)
• Twitter launches Bootstrap, a new platform to build CSS-based apps (digitaltrends.com)