-
Notifications
You must be signed in to change notification settings - Fork 673
Developer Guide: ThinkUp for Beginners by a Beginner
For a beginner developer, finding an open source project to work on can be difficult and daunting. Lots of the projects you know and love are already well established with large communities of developers and their own best practices that might seem alien to you. This is where ThinkUp starts to look really good. ThinkUp has a small developer base (at the time of writing this, 24 developers total) and a well designed and executed development process.
I'm going to try and walk you through all of the things you need to know before diving into the code. I am a beginner developer myself and have been contributing to ThinkUp for a few months so I know what it feels like at first!
First things first, you need to get yourself a copy of the code. I won't go through this because there is already a fantastic guide written for it which can be found here. I will make a few notes for beginners, though.
When I first started developing for ThinkUp the scariest thing was the version control. I had never used Git before and it was totally alien to me (parts of it still are). I also didn't understand how open source software was developed so here is a brief run down for you. (If you want more information on Git and how to use it, there is plenty of documentation online. This is still something I have to do so I can't offer too much help. Maybe someone will edit this wiki page in future to include more Git info? :))
You may be wondering: How does open source software get developed with lots of people making changes at the same time without descending into total chaos? The answer is very simple: version control and branching. Examples of version control packages are Subversion, Mercurial, CVS and, of course, Git. A branch is simply a part of the project that is being developed on by someone. For example, one of my branches is "429-wordpress-plugin-cleanup", the 429 is the issue number related to it and the rest is a description of what I'm doing on the branch.
A lot of open source software uses the branch model and the way it works is that there is a branch called "master" which is the main branch of the project. All changes that are made will eventually end up in there (provided they pass review). You, as a developer, create your own branch of development, write your own code on it and, when you think it's ready, you submit it to Gina for review and she provides you with feedback if changes need to be made. If it's all good and doesn't need changing, Gina will merge your changes into the master branch and you'll end up on the Contributor list. Cool, huh?
ThinkUp follows a "test driven development" model. It's less scary than it sounds. Essentially all that it means is for every bit of code that is written, there is a corresponding test to make sure it works. For example, my first commit on this project was modifying the installer process so you don't need a database set up before installing it. The installer would check if the database existed and create it if it didn't.
Along with this code I needed to write tests for all possible test cases: existing database names, insufficient privileges, invalid database names, invalid database log in credentials, the works. But because these tests exist, the project is far easier to maintain. Every change that is made has the potential to break another part of the code base and the unit tests (the tests are called unit tests) will highlight what part is broken.
If you've used JUnit in Java or any other unit testing package in any other language they all follow more or less the same syntax and ideology. ThinkUp already has a good guide on how to write unit tests but I'll highlight the basic idea:
You create a test case. For example, with the installer I would test making a connection to the database with false credentials (I'm fairly sure I used "localcheese" instead of "localhost" as the database server). Then I would analyse the page that returned from that to search for a specific error string. For some simple example tests, check out the TestOfConfig.php in the tests/ directory.
Yeah, it was a pretty alien concept to me when I started, too. It makes a lot of sense, though, and you'll come to love it in time. ThinkUp has a brief page on their movel-view-controller implementation which links off to the Wikipedia page on MVC which isn't very helpful to a new developer so I'll do my best to explain.
The basic principal behind MVC is separating programming logic from the design and user interface. The models handle programming logic (the PHP part) and the views handle the user interface (the HTML part). The controllers handle deciding which models to use with which views and what information should be sent to the views.
The views are the part that really interested me. They're Smarty .tpl files which are really good at combining simple PHP with HTML. Here's a really cool crash course in how to use Smarty .tpl files. (Note: In that example they use the assign() method to send data to .tpl files but as far as my ThinkUp development goes, I've only seen the addToView() method used. They seem to do the same thing.)
The purpose of the controllers is to use the models to generate data to send to the views. Every exposed page (page that you access in ThinkUp such as index.php, install.php etc.) is generated by calling the go() method of a controller. That go() method will handle all the programming logic and send a bunch of key-value pairs to a .tpl file which will be parsed, the PHP in it will be evaluated, and it will be displayed on the page. Elegant separation of all programming logic from user interface. As a rule, there is no HTML in any file apart from .tpl files (though there is the occasional exception).
That's totally okay. ThinkUp has both a mailing list and IRC channel for this exact scenario! Here's a link to the mailing list and here is a link to the IRC channel. You may not get a reply straight away but anyone who sees your query will endeavor to help you as much as they can!