To Boldly Go...

Jun/26/2014

It seems like an eternity ago now, but my first "real" web development language was Java. I had done some dynamic-ish web sites prior to Java. I built a web interface to an anonymous FTP archive using shell scripts to parse description text files and assemble HTML. I started using Perl for some more sophisticated text parsing, but I was still working with flat files. I knew the next step was using a database, but that wasn't an option with Perl at the time. Java was getting a lot of press and it seemed like a good way to go. My first e-commerce site was build on a Solaris server using Apache and Tomcat and a MySQL database. If there was a Solaris equivalent of apt-get or yum, I hadn't heard of it. I downloaded sources and compiled my own. JSP was released in 1999. I continued to develop in Java and was getting into J2EE when the entire Utah office was laid off in 2003.

I ended up getting a job with a multimedia company that I was kind of excited about. Flash MX and AS3 had just been released and was the next cool thing. I thought I'd be getting the opportunity to get more into Flash development. I was wrong. I ended up being the company's only web developer working in...wait for it...ASP. I still feel dirty. I quit that job and started freelancing in 2006. Looking around at hosting options, PHP was by far the most ubiquitous. Java hosting was almost non-existent. So I made the jump to PHP and the rest is, as they say, history.

Now at my current job we have a web site that was built in Java years ago. How my company ended up supporting the site is a long convoluted story. How I ended up working on it is quite simple. Our Java guy quit and I was the only one who had any Java experience at all. It's been quite the headache. The site was originally developed on a proprietary framework. Essentially the purveyors of said framework said, "We're not interested in supporting you any more. Here's the source code. Now go away." I have a huge 300+ page training manual that is a fine testament to the pointless destruction of trees, but is otherwise useless. We don't even have all the source files. Despite the frustration, I find myself missing Java. Maybe it's just nostalgia, but I think it's the structure I miss. PHP is growing up and moving more in that direction, but there are still plenty of developers out there content to write code like it's 1999. I'm not saying Java is some magic bullet for crap code. You can write crap code regardless of the language you use. The memory problems I'm having with a cron from this Java site are a testement to that. I think I finally have fixed it so the garbage collector isn't thrashing, but it still doesn't manage memory very well. I digress. The point is, I'm feeling like I'd like to brush up on my Java skills.

I'm sure there are plenty who have gone before. Going boldy just means it's just time to jump in with both feet. My history with side projects isn't great, but I've been winding down other committments so hopefully I'll be able to make this work.

Catching up

Jun/01/2014

So after spending a few days getting old posts into Wardrobe, it has become apparent that I need to catch you up on a few things.

Slim

I just haven't had time to do much with it. Obviously I won't be using anything I've written for this web site. I still want to do something with Slim, but I'm not sure exactly what at this point. Hopefully I'll have time to work on personal projects soon.

Sublime Text

After a great start Sublime seems to have stalled. At the time of my original post on the subject, Sublime was on v2. Version 3 was announced and a beta was made available to folks with a paid license. A tentative release date of November 2013 was given. Not that I really expected that to happen. Things happen. Dates get pushed. It's all good. However, the last update to the beta was in Decemeber 2013 and then nothing. Six months later and not so much as a peep from the developer. I understand that stuff happens. Maybe he just needed a holiday. Who wouldn't? Sublime is nagware. I happen to know more than one developer who is fine dismissing the nag and sticking with the free plan. It's quite likely the developer isn't getting the income necessary to support development, which is sad.

The thing is if you're asking people to pay for you product, and some of us have, you need to keep in touch. Even if all you do is make a blog post that says, "So long and thanks for all the fish," people will know you've stopped development and can move on. If you're not getting enough support, say so. If you decided to take a year sabatical, say so. All the forum chatter I've seen is just asking for an update. No one is criticizing the developer for not being done yet. They just want to know if Sublime is dead or not.

Myself, I've taken another look at PHP Storm. I looked at it a while back, but just couldn't get excited about it. I love multiple line editing in Sublime. I use it all. the. time. It wasn't something I was willing to do without. However, PHP Storm's v8 is available through their early access program. It has multi-line edits. So I've been using it for a few months now. I've even been submitting bugs. As IDE's go it's pretty quick. Takes forever to start up, but I can live with that. It's not like I'm shutting it down and starting it up over and over throughout my day. The main plus for me is better syntax checking and code smell that isn't obnoxious. I don't work in a shop that is PSR compliant or even interested in being so. Code smell plugins for Sublime try and enforce PSR standards which just gets in the way. PHPStorm takes a more laid back approach which is nice. I just figured out today that I can have PHPStorm push files I just committed in Git up to a server via SFTP. Super nice for the side project I have where I can't get Git running on the server.

Will I pony up when v8 is released? Most likely.

New Home

May/23/2014

I've just migrated to a new host. I've also changed blogging platforms, because I never do anything small. I'm now using Wardrobe instead of Wordpress. The biggest reason for the switch is I want to learn more about the Laravel PHP framework upon which Wardrobe is based. To a lesser degree, I was feeling like Wordpress was overkill for how I use this site.

I'll be migrating some of the content from the old Wordpress site over the next few days. I'll probably only move the most recent stuff that's still relevent. For example, my short tutorials based on outdated Dojo 1.6 probably won't make it over.

Welcome.

Drowning

Nov/18/2013

Things have gotten a bit out of control, and I haven't had time to keep working on Slim. I'll get back to it eventually.

Slim: Our first view

Oct/26/2013

Unlike more full featured frameworks, there isn't much about Slim that is configured out of the box—at least based on what I've seen so far. Take views for example. Unlike a traditional MVC framework there isn't a folder already designated for views. Since we'll more than likely want to use views before this is all over, let's work on configuring Slim and setting up our first view.

The Slim documentation refers to view files as templates. Indeed the config parameter we'll be setting is called template.path. With that in mind, I added a templates folder to my [project] folder. I also created a css and img folder in my public folder. My folder structure now looks like this:

[project]
--templates
--public
----img
----css

In order to let Slim know where the templates can be found, we need to pass some parameters to the constructor. The Slim constructor takes an associative array of parameter values.You could keep it simple and create your Slim app like this:

$app = new Slim( array(
    'template.path' = '../templates'
));

That's not going to be a very practical solution in the long run. If you look at what Jeremy Kendall did in his Flaming Archer project, he creates a config.php file in the [project] folder and puts all of his config values there, then uses a require statement to get them into his app.

I have some reservations with Jeremy's approach. With the config file in the project folder, it does make it easy to use __DIR__ to build your paths with. However, I'm not a fan of using a return value at the end of an include file. If adding a return statement at the end of an external PHP file did some kind of magic so that the file was scoped like a function, I would probably be OK with that approach. I'm not opposed to magic on principle. Unfortunately, that is not how it works. Variables declared in the config file are still floating around in the global scope. In the interest of keeping things a bit more tidy, I'm going to take a different approach.

No doubt at some point in this process I'm going to need to write my own classes that I will need to make available to Slim. Since we are using Composer to load our classes, we need to tell Composer where to find the files. I'm going to make a 'classes' folder in my project folder. To quote Tolkein, "A precise if not too imaginative name..." There doesn't seem to be much of a convention as to what this folder should be called. Feel free to name your folder whatever you like.

Now we're going to open up our composer.json file and some more info:

{
    "require": {
        "slim/slim": "2.3.*"
    },
    "autoload": {
        "psr-0": {
            "Dezynworks": "classes/"
        }
    }
}

Basically we're telling composer "you can find the namespace Dezynworks in the classes folder." Don't forget that comma after your require object or you won't have valid JSON. Next we need to make a Dezynworks folder in the include folder. Obviously, you can call your namespace whatever you want. If for some odd reason you go ahead and call it Dezynworks, I promise I won't sic my lawyers on you. Now we have a folder structure that looks like this:

[project]
    --classes
    ----Dezynworks
    --public
    ----css
    ----img
    --templates
    --vendor

Since we've modified the composer.json file, we need to update Composer so it knows about the change. From the command line run php composer.phar update. Now that we have told Composer where to find our namespace, let's get going. I'm going to create a Config class and stick it in my classes/Dezynworks folder.

<?php

namespace Dezynworks;

class Config{
    public static function slim(){
        return array(
            'templates.path' => $_SERVER['DOCUMENT_ROOT'] . '/../templates'
        );
    }
}

I'm sure that seems a bit over engineered for a single parameter, but it's unlikely that's the only parameter we're going to need before we're done. It's also likely we'll add a few more libraries that will need their own config parameters. Setting up a config class this way keeps the global scope tidy, puts all our config parameters in one place and allows us to keep them as organized as suits our our personal levels of OCD.

Now we edit our index.php file so the call that creates our Slim object looks like this:

<?php
require '../vendor/autoload.php';
use Slim\Slim;
use Dezynworks\Config;

$app = new Slim( Config::slim() );

Now that Slim is ready, let's create our first template. In the templates folder, I'll create a layout.php file that looks like this:

<html lang="en-US">
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
        <title>Dezynworks | Web Development and Design</title>
    </head>
    <body>
        <?= $content ?>
    </body>
</html>

Now we need to modify our router call.

$app->get('/', function() use ($app) {
    $app->render( "layout.php", array(
        'content' => "Hello again."
    ));
});

A few things of note here. First, we can't call the render function of the app from within our anonymous function because the $app variable doesn't exist within that scope. The use statement takes care of injecting $app into the function scope. Now we can call $app->render() and give it the name of our template file which Slim can find thanks to all the leg work we just did. It should be fairly obvious how we got our $content variable passed into our template. Till next time.