Archive for March, 2008

Dreamhost + SVN + WebSVN = WIN!!!

Sunday, March 23rd, 2008

I recently set up my public Subversion repository – I decided that setting up a sourceforge or google code account for my stuff would just be lame, given that I have my own website that I’ve recently started putting effort into making presentable. By default, however, svn displays a very basic browser that doesn’t really give any info and is just ugly:

crowley’s ugly svn

My 5 year old step-nephew (moptop from here on out) can do better than that. Here’s my how-to for setting up a baller ass looking Subversion tree like this one. Also, I just like ripping on Crowley.

Things we’ll be using:

  • Dreamhost panel’s svn manager
  • Subversion
  • WebSVN – a kick ass php web-based SVN browser
  • Enscript – a GNU app for highlighting source code.

We’ll start with the hardest, yet optional part:

Optional: Installing Enscript

If you want WebSVN to have broad highlighting support, follow this how-to to install it before we begin.

Setting up Subversion

  1. create a subdomain using this page. Mine is svn.mihasya.com.
  2. go to the dh svn manager and set up you repository. The two examples I’ll use are ked_core and mihasya.com. Make sure you make the repository a “public project”. Set up a username or however many you need. Your respositories can now be found at http://your.svn.subdomain.com/repository_name and locally at /home/username/svn/repository_name
  3. Do the usual commit/import routine so your repository isn’t empty.

Installing WebSVN

This part is easy. From your DH home folder run: (you should obviously replace the URL with teh latest WebSVN tarball and the svn.mihasya.com with the appropriate subdomain’s folder.

$ wget http://websvn.tigris.org/files/documents/1380/39378/websvn-2.0.tar.gz
$ tar -zxvf websvn-2.0.tar.gz
$ mv websvn-2.0/* svn.mihasya.com
$ rm -Rf websvn-2.0
WebSVN is ready to go. Going to your.svn.subdomain.com should now load WebSVN with no repositories.

Configuring WebSVN

Also easy. Now that your WebSVN files are in your subdomain’s folder (/home/mihasya/svn.mihasya.com for me) find the includes/distconfig.php and rename it to includes/config.php.

In that file, find the lines that look like this:

// $config->addRepository('NameToDisplay', 'URL to repository (e.g. file:///c:/svn/proj)');
Copy that, without the comments naturally, and change it to point to your repository. My example:
$config->addRepository('ked_core', 'file:///home/mihasya/svn/ked_core');
Save and refresh the WebSVN page – your repository should now appear. You could be done here, but if you’re not lazy, you could really be a rockstar. Like me.

Optional: Setting up Highlighting Using Enscript

By default, my understanding is that WebSVN only highlights PHP – probably just uses PHP’s highlight functions ;) Remember how we (might have) set up Enscript earlier? Well, now find this line:

// $config->setEnscriptPath('Path/to/enscript/command/');
Uncomment it and replace it with your path from step 1. Mine:
$config->setEnscriptPath('/home/mihasya/packages/bin');
Then find this and uncomment it:
// $config->useEnscript();
Enable Additional Extensions

If you’re like me and use Smarty with somethign like .tpl for files that are really mostly html, do this in the same section to tell Enscript what known filetype to associate that extension with:

$extEnscript['.tpl'] = 'html';

Optional (but awesome): Block Ugly UI Using Rewrite

There is still one problem to be solved. Going to http://svn.mihasya.com/ked_core still goes to the stupid old SVN interface (the one Crowley is using above). You can’t be doin that if you wanna be a rockstar. However, there is one thing it remember (which I initially didn’t): you use the exact same URL when running svn commands. Nothing a little RewriteCond magic can’t fix. Put something like this in the .htaccess file in your svn subdomain’s root folder (where we copied WebSVN earlier):

[ UPDATE: turns out you have to put the RewriteCond statement before every rule (if someone has a better way of doing this, holler); also added the [NC] flag to make the condition not case sensitive, just to be safe ]

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !^SVN [NC]
RewriteRule ^ked_core$ /listing.php?repname=ked_core [R,QSA]
RewriteCond %{HTTP_USER_AGENT} !^SVN [NC]
RewriteRule ^mihasya.com$ /listing.php?repname=mihasya.com [R,QSA]
That second line makes sure that the URL isn’t being called by a Subversion client. Browsers will be directed to the pretty new interface, while svn will operate as usual. Fucking WIN!

Conclusion

Now you can be cool like me and show off your code off your own domain with a sweet ass interface. Not like the chumps with that generic garbage… Explore includes/config.php some more if you want to tailor things more to your tastes.

WebSVN TreeWebSVN Single File

ked_core update

Saturday, March 22nd, 2008

Basics

All code for ked_core and my other projects can now be found here.

Slight change in nomenclature (aka stuff I hate) – the package that contains the framework itself will now be called ked_core, to accomodate future projects like ked_pdo and ked_auth that will play nicely with the framework. Those will have to wait until I un-dumbass myself by doing some more reading. And just completely stop giving a fuck about school and dedicate all my time to hacking.

Some General Thoughts

I’ve decided I can’t call it an MVC framework – because I don’t believe in models in the way Rails does. I don’t think an application has to be based around a model. Just because Rails has a built in implementation is not a good reason, to me, to use one. I have legitimately written an application that was very useful, but used NO database whatsoever. Anyone is free to use a 3rd party model implementation or write their own, but ked won’t require one by default.

Change in Goals/Scope

So as I was fucking around with the code, I decided to stop and revisit my goal: building a framework that can follow a site as it grows from something completely tiny hosted on something like Dreamhost to a massively scaled site with its own farm. For that two things are needed: leanness (least possible number of required operations and disk reads/writes per page load) and maintainability. The overall goal is now to be able to just download a ked skeleton to any host with PHP5 (I’m using my 5.95/mo Dreamhost account as a benchmark; if it works there but not on your host, kill yourself), then be able to grow it from there and move it to any other host near seamlessly. The changes to the core are as follows:

  • ked will now only run through a single index.php file, which will then load all the appropriate files for all the controllers. It ends up actually being 1 fewer include per page, thus one fewer fs operation. I realize that isn’t a big deal if APC is involved with opcode caching, but remember – every little bit counts.
    • no apache configuration needed beyond RewriteRules in .htaccess.
  • ked now also supports grouping controllers/views into folders. Naming your controller admin_mainController adn placing it into /ked_app_root/inc/controllers/admin/main.php will work. Your views can then go into /ked_smarty_dir/templates/admin/main/viewName.tpl.
  • Similar functionality for layouts.
  • ked_core is still probably ~100 lines of actual code. Everything uses single quotes and only basic string operations – no regular expressions except in my print_r wrapper dump(). There are minimal advanced functions used – one instance of reflection, I believe.

My general stance on what ked will/won’t do also changes, so it will INDEED now wipe your ass for you for the sake of maintainability.

  • ked will generate controller/view skeletons for you via a webbased control panel (pending user permission limitations – to be investigated)
    • if PEAR_DocBlockGenerator is installed, it will use that to generate docblocks for those skeletons
  • ked will support phpUnit integration (but obviously won’t require it) as well as svn hooks to automatically run the unit testing and append test failure notices to the -m msg, citing who committed the failing code.

To Be Done:

  • the basic ked_admin package for skeleton generation/management (which will, btw, use ked_core ;) )
  • rewriting mihasya.com to use ked_core to demonstrate TEH POWAERS, hence its presence in my subversion tree – you’ll be able to compare the original tree with the ked’d tree.
  • investigating integration with PEAR_DocBlockGenerator, phpDoc, phpUnit, Subversion, and my taint.

Spring Break = SUCCESS

Friday, March 21st, 2008

So I pretty much took a 2 week spring break. Yeah I missed 3 days of class – big woop, wanna fight about it?

San Francisco/Yahoo!

My biggest accomplishment during this part of the trip? Booking my next trip. Management approved my trip to MySQL 2008, so I will be in Santa Clara in April :)

Also had a bunch of very productive meetings on campus, got a bunch done and laid down a good roadmap for the next couple of months. Then I also fucked around in San Francisco for a good two days, because, after all, I was on vacation :D

New York City

Saw a bunch of people, made some new friends, slept in every day and came back rejuvenated and ready to take on the world :)

Mexico

I didn’t go to Mexico, but David did. And he brought me back this:

ball in a cup!

The goal is to get the ball into the cup. Sometimes you will miss the cup, but that’s ok, because the ball is attached to a string which is attached to the cup!

SF = Exciting Stuff

Tuesday, March 11th, 2008

Sounds like, at least from verbal conversations, I get to specialize in UI/Usability when I get going full time.. Sweet, though I must admit I’ve enjoyed my PHP/Apache hackery as of late. I learned a bunch of shit today about how networking is set up at Yahoo! Crippling amount of information, but all very fascinating.

Also might be going to the MySQL conference in a month or so, if I can get Yahoo! to foot the bill that is :D

Writing (another) MVC Framework

Sunday, March 9th, 2008

Over the past couple of weeks, I was hacking up an MVC framework, mostly for my personal use. I am gonna post the code once I’m done, however. I have decided to go back basically to the drawing board with it, and don’t feel like starting right now (on “vacation” in SF) so I’ll just write about it instead.

Why? Aren’t there enough?

Yes, but I can never quite get what I want. Here’s a breakdown of my reasons.

Complexity/Usability

Cake does too much. Zend is a little more lean, but does things in a dumb way that requires lots of typing for really simple things (Zend:RD Frameworks::YUI:JS Libraries), Symfony just just didn’t appeal. There’s actually a pretty good feature comparison for 10 frameworks here. My basic complaint is that they all have too many checks for features. I think I just disagree with the use of the word “framework”

I’m a big fan of the 37signals guys and their general design/development philosophies. However, I think that with Rails they’ve strayed from their own philosophy of doing less, at least from the point of view of an external developer. From their perspective, it’s fine because they build Rails to do EXACTLY what they need, so it works great for them. But for a developer starting to develop his own application, Rails is the Microsoft Office of frameworks, and all the PHP frameworks followed Rails into intense complexity, even calling themselves “ports” of Ruby on Rails.

I’m all for not solving the same problem twice. But I don’t think very many problems are ever the same in the strict sense.

Scale/Performance

The more built in features your framework has built in, the more difficult it is to “stray” from the framework. Cal Henderson (OH SNAP, NAME DROP!) writes in his book on scalable websites about striking a balance between OGF (One Giant Function) and OOP.

As you move further right [towards OOP], you gain maintainability at the expense of flexibility. As you move left, you lose the maintainability but gain flexibility. As you move too far out to either edge, optimizing your application becomes harder, while architecture becomes easier. (13)

Cal classifies things like Rails towards the right; in my opinion Rails along with PHP clones like “PHP On Trax” Undecided fall way too far to the right.

Relatedly, this causes a concern for scale. Sure, it’s nice to be able to develop your application quickly and save the $$ and time (so, once again, $$) from your development budget, but you gotta remember – servers cost money, and your application will need servers for as long as it’s live. If you are lucky and your app takes off, you will very quickly realize that every extra little bit of overhead adds up. If your framework just decides to load sqlite on every page view even though you aren’t using it, you’re going to notice (I’m sure there IS a way to turn this off, but Rails would not function until I installed the sqlite3 gem despite the fact that my entire database.ini was mysql). Every file read/write ends up counting.

My goal in creating this framework was to balance usefulness with performance. It does what I think are crucial things to rapid development, but everything that the most basic application ever can live without is left to plugins. If your application doesn’t use databases, you don’t have to define any database confs.

Also, features like “AJAX” are not appropriate to a PHP framework. A PHP framework should facilitate PHP development. Not write JS code. Not rewrite URL’s (hello, mod_rewrite), etc.

Ease of Installation

I’ve only had to install Rails, Cake, and Zend and was just underwhelmed by how much work it took just to get things started. In my interpretation of it, a rapid development framework should allow for a quick start. If it takes me days just to get the damn thing to “Hello, World!” it’s really not worth it.

Dogfood: The Best Reason

The other frameworks just don’t suit my needs. I’m about to knock out a couple of quick freelance projects before I fully transition from student to “real person”; one is very small and simple with minimal db interaction and a tiny CMS component. The other is quite a bit more complex, with a fairly elaborate hierarchy of pages. The first one obviously doesn’t fit the bill for any of the existing frameworks. The second seems like it (I initially was planning to use Cake when the project was first discussed last spring) but actually messing around with cake proved that I would absolutely hate doing an entire project in it. I needed something simple that I could use over and over on projects of varying complexity without taxing the simpler ones with excess complexity.

So Tell Me More!

OK OK! Here’s a little info on the yet-unwritten barebones mvc framework.

The Basics

My baby is due in about 2 weeks. She’s going to weigh in at about 300 lines, probably including doc blocks. Yup. No more. I agree with Crowley’s assessment: if it breaches 300, start cutting back. That is exactly what happened. I was getting a little trigger happy with the plugin system and just starting confusing myself. “Uh oh,” I thought. “If I’m confused, how will an outside user feel trying to figure this out? Actually fuck em – if I’m confused, I’ve written a bad framework, because it should satisfy me first and foremost.”

I’m going to name it Ked. Why that name? Because it’s short easy to type – 2 of the letters are on home row. Just try it: ked ked ked ked::dispatch ked::$settings… it just rolls off the fingers.

There is, however, a metaphoric component – I didn’t get three liberal arts majors for nothing. Keds are my favorite type of footwear. They are very basic, they are comfortable as fuck, they are good for most situations in life (well, if you’re a programmer and don’t have to dress up for work, anyway), and they will rarely let you down. They are perfectly designed to fulfill a very simple function – cover your feet as you walk around. You can, however, put diamonds or Gucci fabric on your keds if your needs call for it. They’ll still be keds, and will still serve their basic telos but will now also serve as a fashion accessory. If you went to high school in the 2000′s, you just think keds are cool no matter what, but that’s neither here nor there.

This framework will aim to be the ked of frameworks – dependable and simple, yet perfect for its one function and extensible to fill whatever other role you need it to.

The goal is to require as little work for every page view as possible, allowing developers to add additional functionality on a per-controller and even per-action basis.

So what’ll it do?

Well, here’s a list of things it won’t do:

  • Make you a mayonnaise sandwich
  • Interpret and route pretty URLs. Use mod_rewrite, it’s faster.
  • Write your XHTML/CSS and JavaScript for you
  • Load a bunch of code to handle databases that you don’t use on every load
  • Make you type 2 lines of code to do something dumb like set a template variable.
  • Make you change your Apache config. Though using some Apache settings is recommended from a performance stand point, Ked will run on anything that runs a reasonable configuration of PHP5.1+ (5.0 might work, but I haven’t thought about it)
  • Wipe your sysadmin’s ass by being backwards compatible to PHP4. Ked will use some very new and cutting edge tricks to make your life easier. If you are on a host that still runs PHP4, find a new host. Adding checks for PHP4 fail will inevitably inflate the otherwise trim code base.

Fine, here’s what it WILL do:

  • Separate logic from presentation (DUH) and direct traffic appropriately
  • Provide an easy way of passing variables. $this->var in the controller will bind to {$var} in the Smarty template (don’t worry, not all $this-> variables will be accessible from Smarty)
  • Use Smarty. Smarty rules. Don’t fight it. Though someone is welcome to write a plugin that allows Ked to run w/o Smarty.
  • Uhhh… oh yeah, allow some funky plugin interaction.

Pretty short list huh? Yup. It’s a ked.

Too Far…

Thursday, March 6th, 2008
Just pulled up Google Reader on my iPhone while sitting in front of my computer… YIKES… Edit: And kiss my ass, everyone who told me I was dumb for buying an iPhone b/c it doesn’t have enterprise features. Who’s dumb now?