The Lone Star PHP Conference

March 29th, 2011 — 1:13pm


This morning I and fellow DallasPHP-er Jake Smith officially launched the website for the local PHP conference we’ve been working on for the past few months – the Lone Star PHP Conference (happening in Dallas, Tx on June 11th).

It’s a one-day, two-track event that brings together some great speakers from around the Dallas area to talk on loads of different topics. Here’s a few of them from the list:

  • Using PHP and MySQL to Build Applications with Windows Azure
  • Disregard Inputs, Acquire Zend_Form
  • Using Dependency Injection for Proper Unit Testing
  • Drupal
  • Unsung Heroes of PHP

Why another conference, you ask? Well, the PHP community here in Dallas is definitely strong and, if the attendance of our user group meetings is any indication, it’s growing stronger all the time. We’ve been bouncing around the idea of having an event here for a while, it was just finally the right time to step up and organize it. There’s a gap in the area covered by some of the major conferences with ZendCon out in California, and php|tek in Chicago. The CodeWorks conference has been here in town before, but they made the move down to Austin last year. It may not be the biggest conference out there (or the most well known) but we hope that it’ll bring the quality content to the DFW masses they expect out of a great conference.

The response so far has been great so far and tickets have already started selling, so if you’re planning on attending, be sure to grab your ticket – space is limited! The event costs $60 for the full day, including a lunch and an after-party event too. If you’re out of town and wanting to come in, we have some special rates there at the hotel you can get for that Friday and Saturday night – just email us and ask to get the details.

Lone Star PHP Conference: http://lonestarphp.com
On Facebook: http://facebook.com/lonestarconference
On Twitter: @lonestarphp

2 comments » | Community, PHP

It’s not a conference… (redux)

March 19th, 2011 — 5:10am

It’s interesting – sitting here writing a few emails, sending a few tweets – I was reminded of a me from not so long ago. He was the one that tried to convince you that conferences aren’t about the talks. He pointed out that the real key to conferences was the people you met there. I’d sort of forgotten him until just this morning, and I wanted to invite him back to the stage.

See, the key to it all is the people. Sure, you can talk about or another specifically, but then you’d lose sight of the one thing that binds them all together. Without the community attending these events, well, there’d be no event at all. It takes all kinds too. There’s the first-timer that’s not quite sure about everything and everyone, but recognizes names from blogs and the speaker list (hint: this was me). There’s the seasoned conference-goer that has been around the block a few times and knows how things really work and then there’s the tireless staff of the events that work sometimes all year long to pull these events off as flawlessly as they can. Each and every one of them has a place in this community but the key is – they’re all people just the same. Without that human connection between them, the community fails and falters and could just sputter and die like we’ve seen from other languages in the past.

Conferences with their talks and tutorials are great – don’t get me wrong. That’s what gets me to the event half the time. There’s several sessions that I’m looking forward to at this year’s tek and PHP Community Confernece (oh, how I wish i’d been accepted to DPC) but what I’m looking forward to the most is seeing my friends. IRC and email just doesn’t cut it. Sitting down with a group of people that get me and know me, either through the work I’ve done or just from talking online, is priceless. We bounce ideas off of each other, crack jokes about the downfalls of other languages (with names based on precious stones) and just generally have a good time.

There is no other place like it and my wish for you is that you pick one of the upcoming conferences and get out there. Sure, the talks are great, but being able to sit down with other developers that understand where you’re coming from and might know where you’re headed is something to treasure.

Oh! And don’t forget – if you can’t make it to a conference, there’s an excellent alternative….your local user group! There’s a whole group of people right in your backyard that have all of this and more.

Comment » | Community, PHP

Why Community Matters… (Updated)

March 18th, 2011 — 9:31pm

It’s easy for us to look around at the technology we work with every day and think that we can solve all of the worlds problems with a few lines of elegant code. We think that just because we have a mastery of our language of choice, that we can conquer any challenge we might face. The only problem is that we’re forgetting one thing. No matter how much code you write or how much time you spend pouring over that shiny new architecture you’ve dreamed up, there’s one thing that can never be replaced – the human element.

Most of the developers I know have started off with a language the same way – they heard about it from a friend. They casually heard the name “PHP” dropped in a conversation and either (depending on how outgoing they are) jumped in to the conversation or made a dash home to look up what everyone else seemed to be talking about. Without this word of mouth, I dare say quite a bit of the technology that we have today wouldn’t be around. Think about it – how many times have you looked at a new language or bit of tech just because someone else you trust said it was cool. Sure, it might sound a little like siding with the popular kid, but what happens if that kid’s the one who’s right? That language may be the next big thing – if not for the online community as a whole, then just for you and your development.

Think back to when you first started programming PHP (that may be yesterday, that may be ten years ago) and think back to all of the influences you had along the way. Chances are you didn’t make it to where you are today without a little help. You found blog posts of others that solved the same problems, you hopped on IRC and talked with like-minded folks trying to overcome the same hurdles and you shared you own experiences for the future generations of web developers to learn from. You’ve come full circle, sharing what you know back with those who need it the most. You’re a contributing member of the community.

So, why am I writing this if it’s all so obvious to even the most casual observer? I wanted to reinforce the fact that, even if you’re new to the community or you’ve been writing PHP so long you dream about namespaces and PHP6, you can always be more involved. Technology is great, but really – people are better. I can’t recommend enough the effort that the PHP Community Conference is doing to bring this human aspect back into the conference scene. They’ve taken the traditional conference mentality, turned it on its side and put an extra helping of emphasis on the thoughts behind the technology and less on the syntax of the day-to-day. This approach provides an interesting perspective, different from the usual track-based methods (similar to the Brooklyn Beta event).

If you haven’t looked at the conference, time’s getting short – it’s happening about a month from now, April 21st and 22nd, in Nashville. I’ll be there as a speaker talking about my first PHP love – PHPDeveloper.org and doing what I can to give back as much to the community as possible. Because really, without each other to help us through, none of us would be where we are today.

UPDATE: I want to take a second to apologize for any poor choice of wording I’ve used in this post. My intent wasn’t to make conferences like php|tek or ZendCon seem less in comparison to the PHP Community Conference. It was more of a commentary on the different conference styles – the “why” PHPComCon offers rather than the “how” sessions that several of the others provide. The ironic thing is that I’m also in the process of planning my own conference and it follows the track-based ideas. It’s a difficult process and I have a growing respect for people like Keith Casey, Marco Tabini, Cal Evans and the scores of other folks behind the scenes of these excellent events. They work their hardest to keep people from “feeling like a number” during their events, and – especially tek – keeping the community as a large focus. My hats are off to them for planning not only quality content during the day but fun, engaging activities during the evenings that bring community members together from all over the world to laugh, enjoy a few beers and shoot the breeze about all things PHP.

Comment » | Community, PHP

Ideas of March

March 15th, 2011 — 7:06am

In an effort to spotlight what is slowly becoming a lost art (blogging), some of us in the PHP community have banded together today to talk about the active sharing of ideas and opinions that come with blog entries. Twitter (or Identi.ca!) ain’t got nothing on it. One-hundred and forty characters is nice, but there’s something to be said for a well-written or well-researched blog post. I can’t tell you the number of times that I’ve searched for a problem, usually the obtuse one that only seems to come up once in a blue moon, and find the answer on someone’s blog.

If you’re among those in the high business world, you’ve heard the cheesy term “knowledge transfer”. Yes, I cringe too even just to say it, but it gets the idea across. Blogging is so much more than vanity posts talking about funny things someone’s dog did. Writing up a blog post is an opportunity to take a small part of what’s in your head and share it with the rest of the world. It gives you an outlet, either creative or technical, to bring your message to the masses. This is the real key. When you blog, it’s not just about you anymore. You’ve taken a part of you, a sliver of your experience finding and fixing that bug or researching that old technology to write an API for it, and shared it with the world in a single click of a button.

It’s been done all through history – the passing down of knowledge from one generation (of programmers?) to another – and there’s no reason to stop now. I hope you’ll join me in making March a true month of ideas. Slow down and take the time to write a blog post or two. It doesn’t have to be a work of art. It doesn’t even have to be very long – just a few sentences will do. Write about something you care about, some project you’re working on that you’re proud of or just about the general state of the PHP community. It’s your blog, you write what means the most to you.

“If you have knowledge, let others light their candle in it.” – Margaret Fuller

3 comments » | Community, PHP

I don’t understand the 9-to-5

February 11th, 2011 — 9:08am

No, this isn’t another post about taking that step out of the corporate world’s 9-to-5 routine and venturing out on your own. (Though that would make for an interesting future post). This post is more of me asking a question of the development community – PHP or otherwise – to help clear up something in my mind. Let me set the stage…

I’ve been developing PHP for….well, let’s just say a long time now and in that time I’ve come to appreciate the quirks of the language and have had a real hunger to find out more about it. It’s a constant friend in my day to day life. I have multple side projects going that use it (PHPDeveloper.org and Joind.in), so PHP is a huge part of my life. Along with this comes the community, a constant stream of new information and people I can sincerely call friends even though we’ve only met a handful of times. It’s the language that brings us together.

Now, back on my wheel again – what I don’t understand is this completely foreign concept of people that just do this as a 9-to-5 job. They come and sit at their workstation and write their code then, at the end of the day, they switch it off and go do something else. I see them writing their code (yes, some of it’s pretty bad) and I wonder how they can’t have that drive to constantly better themselves by doing more than just pushing buttons and earning a paycheck.

So, dear internets, if you could help me out on this – I’d really like to understand the mindset of these folks. I don’t know if I’ve ever been in their shoes and I’d really like a glimpse inside their heads.

Some comments from IRC and Twitter so far:

  • jbafford: they’re people who think they can make good money programming, as opposed to, people who program to solve problems
  • pierrejoye: usually having other time consuming activities don’t allow one to do more. The few doing nothing but 9-5 are social cases

40 comments » | Development, PHP

How long is too long (for unit test method names)?

January 12th, 2011 — 3:44pm

As I ws working on some new development in our codebase this morning, I started updating some
unit tests to match. I was looking through the code for one of them and came across a test name that was easily 50 characters long and
it got me wondering – what was the popular opinion on naming conventions and commenting in unit tests. Obviously, there’s some things
(like annotations) that have to be in comments, but do you sacrifice clarity of a comment for a method name that you can basically read
like a novel?

I mentioned something on Twitter about it and here’s some of the responses I got:

——————————–

Rafael Dohms (rdohms)
@enygma @elazar @bdeshong taking into consideration PHPUnit and its use of method names (like testdox) i would focus more on name not doc
2 hours ago

weierophinney (weierophinney)
@enygma I don’t document my tests; the test name and test content *are* documentation. /cc @elazar @bdeshong
2 hours ago

weierophinney (weierophinney)
@enygma I do those all the time. For use with #PHPUnit’s testdox output. :)
2 hours ago

Ralph Schindler (ralphschindler)
@bdeshong @elazar @enygma if you are using PHPUnit, run the tests with –testdox, you’ll see the benefit of long test names :)
2 hours ago

Chris Cornutt (enygma)
@mwillbanks ah, good point…I can see how that’d be handy heh

Mike Willbanks (mwillbanks)
@enygma putting it in a docblock is nice, however, when running it on a CI server it is nice to see what broke by method name and test name
2 hours ago

Mike Willbanks (mwillbanks)
@enygma I think we have one that is almost 100 characters :) here is 1 example: testEditActionRedirectWhenJournalEntryNotFound
2 hours ago

Brian DeShong (bdeshong)
@enygma @elazar 120 characters? :)
2 hours ago

Michael Maclean (mgdm)
@enygma around the 100 character mark? :)

2 hours ago

Chris Cornutt (enygma)
@elazar @bdeshong ah, but where should method names end and docblocks begin? ;)

Brian DeShong (bdeshong)
@enygma If the method name is long, but descriptive, then that’s good. Descriptive test method names are better than short ones.
2 hours ago

Matthew Turland (elazar)
@enygma Better to be verbose and accurately descriptive than overly concise and obscure? :P
2 hours ago

jcarouth (jcarouth)
@enygma Hey, I’ll take that over testApp1() and testApp2() any day.
3 hours ago

Chris Cornutt (enygma)
well hello entirelyTooLongUnitTestMethodName, nice to meet you
3 hours ago

——————————–

That last one was my not-so-innocent comment that started the whole thing off. I’m still interested, though, in what developers
out there think is a good point to switch from documenting via the test functions name and moving it up to a docblock comment. Seems
like there’s arguments for both sides and I’m not sure if there’s a “winner”, but it’s always fun to get opinions.

What are your preferences in unit test naming versus commenting?

10 comments » | Development, PHP, Testing

Using Models in Fuel

December 23rd, 2010 — 3:31pm

In my previous post on using the Fuel framework I looked at the basics behind getting a site up and running. This time I want to take it a step further and tell you a bit about my experiences getting a Fuel application to talk to a database (in my case MySQL). To learn the process, I fell back on one of my standby sites that’s been rewritten in a few different frameworks now including Solar and a really, really old version of the Zend Framework. It’s not an overly complex site, but the version is starting to show its age. So, I usually take that as an opportunity to rewrite the site in something different, just for the experience.

I’ve already started on a version with the latest download of Fuel and, as a part of it, explored the database model connectivity feature. Now, all of this code is generated from me just looking at the source (since there’s no docs to speak of *cough*) so there’s probably a better way to do some of this that I don’t know. So, lets get started with a basic model.

In my database, I have a few tables – two of them are the “news” and “news_tags” tables. The relationship between the two is news.ID -> news_tags.news_id. Thankfully it works out that this is the default mapping for the relationships between the models. More on that later though…here’s my sample SQL:

create table news (
     news_title VARCHAR(200),
     news_story TEXT,
     date_posted INT,
     ID INT NOT NULL AUTO_INCREMENT,
     PRIMARY KEY(ID)
);
create table news_tags (
     news_id INT,
     tag_name VARCHAR(50),
     ID INT NOT NULL AUTO_INCREMENT,
     PRIMARY KEY(ID)
);

Let’s start with the model files – one for each of the tables. Here’s the basic structure of the file:

<?php
namespace FuelAppModel;
use ActiveRecord;

class News extends ActiveRecord/Model 
{
     // define a sample method
     public function getLatestNews()
     {
          $results = $this->find('all',array(
               'select'        => array('news_title','news_story','date_posted','ID'),
               'limit'         => 10,
               'order'         => array('date_posted','desc')
          ));
          return $results;
     }
}
?>

This is enough for Fuel to now know about the “news” database table. Obviously, you’ll need to have the database connection information correct in your db.php to connect to your instance. A few things to note here – the namespace loads in the base Model functionality so the News class can extend the ActiveRecord bits it needs. The ActiveRecord functionality is contained in a package in the standard Fuel download.

In this model, I’ve defined a simple function to pull out the latest news from our “news” database table. This uses the “find()” method that comes with the ActiveRecord stuff. That first parameter can be one of a few things.

  • An ID number of the record you’re looking for
  • The string “all” to return all matching rows from the where
  • The string “first” that essentially puts a “limit 1″ on the end of the statement

The second parameter sets up the rest of the SQL statement – the “select” array lists the columns to fetch, the “limit” restricts the results and the “order” allows you organize the results by a column. There’s also “offset” and “where” that can help get it more specific. The results are then returned back from the method. If you’re more in the “heavy controller” camp and want to do more complex stuff in there, you can also make a model object inside your controller:

<?php
namespace FuelAppController;

class News extends BaseController
{
     public function action_index()
     {
          $News = new FuelAppModelNews;
          $results = $News->find('all',array(
               'select'        => array('news_title','news_story','date_posted','ID'),
               'limit'         => 10,
               'order'         => array('date_posted','desc')
          ));
     }
}
?>

This essentially does the same thing. Now, lets talk about conventions for models here. If your table name is one word, it’s simple enough – for the “news” table, the model’s name is “News” and the file in /classes/models is “news.php”. For something a bit more complex like “news_tags”, you name the file “newstag.php” and the class “NewsTag”. Note that it looks for the singular version of things – “NewsTag” even though the table is “news_tags”.

Simple, right? Well, if all you need to do is make basic queries and pull that data back out, you’re all set. You can stop here. If, however, you need something a bit more complex like say, table relationships, keep reading. Sure, you can manually join all of your data together, making multiple queries and looping through endless loops to match things up. If you want to save some time you can use the table relationships build into Fuel to do the work for you. There’s currently three different kinds – belongs to, has many, and has one. For the sake of example, I’m only going to show you a “has many” example on our “news” to “news_tags” tables.

Setting up the relationship is super simple. In our News model, we’re going to set a new class property to tell the framework about the relationship:

<?php
namespace FuelAppController

class News extends BaseController
{
     public $has_many = array('news_tags');

     public function getNewsDetail($newsId)
     {
          $results = $this->find($newsId,array('include'=>array('news_tags')));
          return $results;
     }
}
?>

Don’t look at the “find()” call yet, lets concentrate on the new property. This “$has_many” property lets us define the table names we want relations to. By default Fuel tries to look at the other table for a column matching the [current table]_id pattern. Thankfully, we have one of those: the “news” table’s ID relates to “news_tags.news_id”. Works like magic! Additionally you can also define other parameters to manually specify things like the column name to map to.

Okay, let’s look at that find now…we have our relationship defined to the other table, but Fuel knows we might not always want to include that data on every call. To let it know when to pull the news_tags data in, you have to specify it in the “include” parameter of the find() options. When the query runs and the data’s returned, you’ll have the news_tags data in $results->news_tags for your consumption.

There’s one slightly tricky thing that I came across when working with the model features. When it tries to do the join, it looks at the name of the model class it’s trying to use and pulls the name from there. In our case “NewsTag” isn’t the right name for the table. You can however define the table’s name in the $table_name property of the model, but that didn’t seem to cooperate either. It looks like the fault lies in this chunk of code in the “hasmany.php” extension of the ActiveRecord component, around line 212:

<?php
//....
$dest_table = AppInflector::tableize($this->dest_class);
$source_table = AppInflector::tableize($this->source_class);
$source_inst = new $this->source_class;
$dest_inst = new $this->dest_class;
$columns = $dest_inst->get_columns();
//....
?>

In the above snippet it tries to run the “tableize” inflector on the model class’ name to pull out the table. In our case, though, the names don’t match and unfortunately the join() method doesn’t seem to care about the $table_name value and just keeps going on its merry way. It’s a pretty simple fix, thankfully:

<?php
$dest_table = (isset($dest_inst->table_name)) ? $dest_inst->table_name : $dest_table;
?>

With this defined, you can tell it that “$table_name = ‘news_tags’;” and it’ll respect it.

For those used to the more object oriented method of models, there’s also the usual CRUD methods you can use to manipulate the objects:

  • save()
  • update()
  • destroy()
  • and, of course, the find() call

I hope this was helpful and like I said, I’m sure there’s a few things that I didn’t get quite right just because I was fishing through the source to figure them out. I’ve been working on some simple templating for the site, so maybe I’ll write up a post on that next. As always, please point out my mistakes :) That’s the only way to learn!

4 comments » | Development, framework, PHP

A First Look at Fuel

November 24th, 2010 — 11:47pm

UPDATE: I didn’t really mention that Fuel is an open source project. If you want to help out, head over to their github page, fork your own repo and get submitting!

UPDATE UPDATE: I’m not actually affiliated with the Fuel project, just a user. Please direct all suggestions over to their contact form or comment on github. thanks :)

There was an announcement a while back from Phil Sturgeon and a few others (shortly after some issues came to light with a certain other framework) about a new framework they were developing that came to be called Fuel. According to their site, the goal is to be:

a simple, flexible, community driven PHP5 framework. FUEL aims to take the best idea’s from a bunch of frameworks, throw away the “not so good” stuff, and create one awesome framework. It is provided under the terms of an MIT License, which means it’s free to use in your personal, commercial or enterprise projects.

What’s that? Why does the web need another framework? Well, to be honest, it doesn’t – but there is one thing that Fuel has going for it. If you’re one of the many CodeIgniter users out there, you’ll feel almost immediately comfortable with it. Since the devs are CodeIgniter fans themselves, they’ve built a lot of the same feel into how Fuel handles your applications. Unfortunately, there’s not a user guide for it yet, so I figured I’d share some of my experiences with it and maybe get you set down the road to fuel-ing your app (yep, that cheesy pun was required).

So, to get started, here’s some simple installation instructions:

  • Grab the latest source from Github (this will probably change when they make releases)
  • Unpack the files into a web-accessible directory. Mine are in /www/htdocs/fuelapp
  • There’s a /public directory in there – that’s where you need to point the DocumentRoot to
  • Make sure that AllowOverrides is set to use .htaccess and that mod_rewrite is installed and working
  • Move the “example.htaccess” file over to just “.htaccess” to make the rewrites work
  • At this point, when you visit the host for your site, you should get the “Welcome” message
  • Be sure to chmod the app/cache and app/logs directories so that the web server user can read/write to the directories.

That should get you started and have your basic application structure all set to go. In the basic layout, your application will live in the /app directory (makes sense, eh?) with the actual framework living in /core. As far as the three pillars of a MVC framework – they’re in classes/controller, classes/model and views. There’s also a config directory that houses the configuration files for your application.

Let’s start with the controllers – here’s an example snippet from the welcome controller showing you a basic controller structure:

<?php

use FuelController;

class Controller_Welcome extends ControllerBase {
	public function action_hello()
	{
		$this->output = 'Hello '.$this->param('name');
	}
}

This action is called at http://localhost/welcome/hello (obviously replacing the hostname with yours).

If you haven’t seen something like the “use” call before, don’t worry. It’s just namespacing. The framework is PHP 5.3 only, so they can use fun things like namespacing and closures. In the example above, they load the FuelController namespace and extend the ControllerBase by default. There’s some naming conventions to look out for in controllers:

  • Controller class names should be “Controller_*”
  • They should extend ControllerBase
  • Methods should be “action_*”
  • Output pushed to the view belongs in $this->output

Something you don’t see in the above example is how to interact with the view. You’ll need to use the View class to get your data loaded into the right place. Here’s an example of that:

	public function action_index()
	{

		$arr = array(
			'data'		=> 'test data',
			'partial'	=> View::factory('test/partial')->render()
		);

		$this->output = View::factory('test/index',$arr);
		
	}

If you’re quick, you’ve spotted the “partial view” I’ve simulated. By calling that “render” method on the view object, it returns the results as a string that can be appended. The parameter in that “factory” call is the path to the view file. So, the string “test/index” refers to the file /app/views/test/index.php.

There’s already some handy built-in helpers for the framework. It seems like all of them I saw were able to be called statically. So, for example – here’s how you could use the Uri helper:

	public function action_uri()
	{
		$detect = Uri::detect();
		var_dump($detect);
	}

Oh, and one last thing I know some of you are wondering about – database connectivity. Right now, there’s only MySQL connectivity, but I’m sure that’ll change quickly. Here’s a simple database example to get you started:

	public function action_database()
	{

		$db = Database::instance();
		$tables = $db->list_tables();
		var_dump($tables); echo '<br/><br/>';

		$result = $db->query(Database::SELECT,'select * from test_data',false);
		var_dump($result); echo '<br/><br/>';

		var_dump($result->current());
		$result->next();
		var_dump($result->current());

		$this->output = 'test';
	}

Instead of just returning arrays or whatever, the datbase calls by default return iterators. I nice touch in my opinion that could go a long way to help SPL adoption. You can also define an object type on the “query” call that lets you map to and object type.

So far so good…like I said, if you’re a CodeIgniter fan, you’d do well to check out Fuel. It feels more like what CodeIgniter should be when it grows up and joins the rest of the PHP frameworks in the PHP5+ world. I’ve already submitted a small update back to the framework and can already say that the community for it is friendly and open to whatever help they can get. Dan Horrigan, Phil Sturgeon and Jelmer Schreuder are doing a great job so far and I look forward to some more great things to come.

I’m going to continue messing with it and will try to post any fun things I might come across. Feel free to ask me about installation or some of the basics of the framework. I’m happy to share what I know.

Oh, and for those wondering, here’s my sample controller I’ve pulled these samples from:

<?php

use FuelController;

class Controller_Test extends ControllerBase
{

	public function action_index()
	{

		$arr = array(
			'data'		=> 'test data',
			'partial'	=> View::factory('test/partial')->render()
		);

		$this->output = View::factory('test/index',$arr);
		
	}

	public function action_caching()
	{
		Cache::set('mykey','testing');
		$cacheOutput = Cache::get('mykey');

		$this->output = 'cache output: '.$cacheOutput;
		Cache::delete('mykey');

		$this->output.='cache after: '.Cache::get('mykey');
	}

	public function action_uri()
	{
		$detect = Uri::detect();
		var_dump($detect);
	}

	public function action_database()
	{

		$db = Database::instance();
		$tables = $db->list_tables();
		var_dump($tables); echo '<br/><br/>';

		$result = $db->query(Database::SELECT,'select * from test_data',false);
		var_dump($result); echo '<br/><br/>';

		var_dump($result->current());
		$result->next();
		var_dump($result->current());

		$this->output = 'test';
	}

}

?>

12 comments » | framework, PHP

One ToDo list to rule them all?

November 16th, 2010 — 3:32pm

Okay, so _ I’m going to put this out there so I can get some feedback. I’m looking for a good To Do list manager with a few criteria:

  • I’d love for it to have desktop software that would sync with the site (or some other resource) and allow me offline access to the lists
  • It needs to be able to prioritize items
  • It should definitely allow main and sub-categories (one level of categories? that’s crazy talk)
  • The desktop software would need to be cross-platform (pc & mac) – maybe an AIR client?
  • Bonus points if it allows sharing between users or just public access to the lists (RSS?)
  • Mobile support is cool, but not required

I like the simplicity of some of the tools out there, but none of them seem to meet what I’m looking for. Is there anyone out there that’s come across something like this? It’s driving me nuts that there’s not one that’ll fit my needs.

3 comments » | Development, Personal, Web

A Partial Review of “Test-Driven JavaScript Development”

November 1st, 2010 — 2:21pm

So ever since the fine folks at Addison Wesley sent over a copy of Test-Driven JavaScript Development (by Christian Johansen) I’ve been trying to wrap my head around a new sort of testing when it comes to web apps. I’m not even half-way through the book and I’ve already had my mind blown by advanced javascript and testing methods that I just never thought about when I work on my frontends.

I’m a big fan of unit testing and promote it whenever I can – not only does it help create a code base that a better quality, but it also lets you keep things consistent. No more of the “cross your fingers” kind of coding. A good, well-written set of unit tests can save you a whole world of hassle in the long run. Taking it one step further, you get to TDD (test-driven development) where you write your tests before you even write your code. You start with the usual “W”s – why, where, when, how (yes, I know that last one’s an “H”s) and develop the test for those rather than looking at a current chunk of code and testing what it already does. There’s some people that swear by it, one of them being the author of this book.

He starts with an introduction to TDD and a general how-it-works with javascript quickly followed by an introduction to his tool of choice – JsTestDriver. All of the test examples in the following chapters are run with this tool. Thankfully it’s simple to set up and even easier to write tests for. He shows some introductory tests to help you get familiar with things before diving into the next section – testing javascript itself.

I have to admit, this section left me at a loss for words. I thought I knew a good bit about how javascript works, both out in front and behind the scenes. I was surprised, however, just how much of the functionality he tested I had no idea worked that way. It’s pretty in-depth, so if you’re a beginning javascript dev, you might go read some more tutorials before diving right in.

I’m just now getting to the “Unobtrusive Javascript” part of the book (Part 2, Chapter 9) so I still have a ways to go, but each page is enlightening, especially for some one like myself that’s has a primary focus on backend work and unit testing. I’d definitely recommend this book to anyone looking to get into testing their frontends – it’s a great resource and can probably teach you a thing or two.

I’ll try to put up another post when I get closer to the end – it’s hard to find time to sit and read these days, but just little nibbles at a time work just fine.

3 comments » | Book Review, Development, javascript, PHP, Testing

Back to top