www.nickhodge.com

Notes from De-commissioning old Con­tent Man­age­ment Sys­tem: The Mun­gen­etEn­gine. The engine has rendered 10 mil­lion image views and 2.5 mil­lion page views from hand­coded MySQL and PHP.

1. “cod­ing” in PHP feels wrong, wrong, wrong. A little dirty. After 6 months, I feel I should be writ­ing in C#, Iron­Py­thon; at least some­thing decent. Not PHP. It’s too lose. Like Visual Basic. Sadly, this will prob­ably the last time I use PHP for a sig­ni­fic­ant amount of time as I move to CLR/DLR style lan­guages and platforms.
2. The code to com­plete the trans­ition was a mere 138 lines of PHP; ref­er­en­cing some open­source XML-RPC lib­rar­ies (to insert blog entries over the wire), and 2110 lines in the base lib­rary that acts as the old engine.
3. Turn­ing off http://twitter.com/nickhodge for a few days helped pro­ductiv­ity. Also work­ing at home dur­ing the shenanigans of APEC 2007 helped pro­ductiv­ity, too.  I also stopped being as respons­ive on email, voice­mail etc to get some good “focus” time to get this happening.
4. The code I am put­ting out to pas­ture was largely writ­ten in 2001–2. Small pieces were tweaked through 2002–7. It has sur­vived PHP 4.0.x to 5.2.x pretty unscathed. http://nickhodge.com/mn8/section/23/ details the his­tory and philo­sophy of the self-written and main­tained CMS.
5. Word­Press is not the final step. It is just a good time to move a plat­form I trans­ition to other places in the future, some­where in the cloud.
6. As Joel Pobar says, “hav­ing no policy on cache is a memory leak”. In my instance, the smart­ness of a cache for pro­duc­tion use to reduce hits on MySQL res­ul­ted in a bug that took 45 minutes to track down. Not as a memory leak, just unex­pec­ted behavior.
7. Strategy: get images from the data­base into a fixed file sys­tem under http://media.nickhodge.com/. As per the wise guid­ance of UncleMike, this future­proofs my data. A part of the strategy is to move the rss feeds to a local feed sys­tem as I am not trust­ing feed­burner and feed­jum­bler for stats right now.
8. Rendered pages: best thing to do is “wrap” what is con­tent with mark­ers, render the page via CURL, and per­sist what is wrapped into the Word­Press CMS. The how came to me in an after­noon nana nap. Con­scious brain was on hold, and the real smarts came to the fore. 
9. Reg­u­lar Expres­sions. Why-oh-why where they inven­ted to make my brain explode? Thank­fully, the intar­webs helps.
10. A shim of the Mun­gen­etEn­gine will remain in place to “301″ old URLs to new URLs. Full page ren­der­ing and image/binary ren­der­ing will be turned off. There­fore, the import mode will not be Word­Press RSS style import. Using http://www.dentedreality.com.au/bloggerapi/ to post via XML-RPC
11. Mangling dates, and doing hand-crafted fixes to my Word­Press XML-RPC (note: this is patched for 2.3, evid­ently) took some hours.
12. There are 761 blog entries prior to trans­ition.  From an earlier blog trans­ition on August 8^th 2006, the count was 371. There have been 390 entries since. Post trans­ition, there are now 940 posts.
13. Raw trans­fer com­plete at 6:50pm 5^th Septem­ber 2007.
14. To com­plete: neater clas­si­fic­a­tion of the new entries.

Thanks for the morn­ing diver­sion, Chris. The RSS 0.92 Feed feed is now correct.

One of the pleas­ures of all this travel for Adobe is being able to visit my favour­ite place in the world — west coast of the North Island of New Zea­l­and. At the begin­ning of the cur­rent road­show, I took Jane Brady and Tim Cole to Piha and Kare Kare: Tim Cole, Jane Brady and Nick Hodge in New Zealand

90% com­pleted a Visual Basic fron­tend to the mun­gen­eten­gine. This should make it easier to update and edit some of the con­tent on the site, with resort­ing to copy and paste. The ori­ginal inter­face is a forms/web based thing.

Strange days. Had an email from a Dreamweaver/Coldfusion MX user say­ing that the Ran­dom Neil Finn Lyric Server was the first suc­cess­ful SOAPweb ser­vice he could con­nect to. Noth­ing like help­ing the competition!

GoLive 6: Adobe’s Open Source Embrace. A good read if you are into data­bases, PHP, GoLive et al.

As as 1.30pm, the Ran­dom Neil Finn Lyric Server has served 1000 lyrics!

OK, so I felt guilty. Spent some time cre­at­ing table ver­sions of the tem­plates for those few people who are stuck in the late 1990s with Nets­cape 4.x and sim­ilar. The css is also cus­tom­ised slightly, too. mun­gen­eten­gine will dynam­ic­ally determ­ine the browser you are using, and serve up the same con­tent, just slightly mod­i­fied depend­ing on your browser.

At 8.30am today, mun­gen­eten­gine had served 10000 unique page views to 1829 unique viewers.

Earlier today I had an idea of a web ser­vice that I could imple­ment here. To the right is from this web ser­vice on mun­genet — the Ran­dom Neil Finn Lyric Server. This is imple­men­ted as a SOAP ser­vice installed on my host, backended by a MySQL data­base. Includ­ing the inter­face to the data­base and the SOAP ser­vice, it took about 4 hours to complete.

Lynn Grillo on Cre­at­ing HTML emails with GoLive

I’ve just tried to load mun­genet in Nets­cape 4.7 and real­ised its very broken. I’ll have to look into how to fix this on the server side. The good news is that things are still cool with the newly released pre­view of Nets­cape 7. It looks like we’re back into web browser ver­sion num­ber wars.

note to self: WSDL is easy, as long as you name things intel­li­gently and match the code and parameter’s nam­ing conventions

I can insert SOAP con­tent into the HTML stream. This is the mech­an­ism I am going to use to do cross mun­gen­eten­gine con­tent replication.

Well, after using a SOAP client/server com­bin­a­tion in the mun­gen­eten­gine, I can call the external server ask­ing for a con­tent frag­ment and insert it into this site. Done. Dur­a­tion 45 minutes. SOAP (ref: SOAP Spec); is a W3C pro­tocol for client-server com­mu­nic­a­tions using XML as the pay­load format and HTTP as the transport.

The key point is that I can place con­tent in one place (extern­ally, for pub­lic view) and have the internal site seem like its ‘rep­lic­at­ing’ the con­tent. The way it works is to call a SOAP object request­ing a par­tic­u­lar mcid from a server; this is inser­ted this into the client’s HTML stream.

The end of another big road­show, a week until my birth­day, and I’ve just worked out nes­ted, CSS positioning. Nearly time for Mungenet7. I’ll dis­card­ing tables for pos­i­tion­ing of ele­ments as my base page design, and repla­cing them with CSS layers.

My last blog entry for 2001. What a year. I’ve been spend­ing my hol­i­days adding two extra entries in the T3 sec­tion. There are also some extra fea­tures in the mun­gen­eten­gine

For those inter­ested in InDes­ign. The ‘engin­eer’ men­tioned is, err, me.

How the mun­gen­eten­gine works is a quickie descrip­tion of what is going on behind the scenes.

There’s another rewrite in my head. In my fea­tures data­base, there are 21 to-dos. So many ideas, so little time. The more I think about mun­gen­eten­gine, I real­ise that there is a bet­ter way. At the moment, the render engine is tied up in one object– not the best way to cre­ate a OO application.

When you ‘write’ your own applic­a­tion, and run it live, its easy to see how dif­fi­cult it is to cre­ate large applic­a­tions like Pho­toshop or InDes­ign. Let alone an oper­at­ing system…

Wel­come to Mun­genet 6.

This one is a little dif­fer­ent to the pre­vi­ous ver­sions — the page frag­ments are stored in a MySQL data­base and dynam­ic­ally cre­ated using a 1000-line PHP opus called the mun­gen­eten­gine. The struc­ture of the site is also stored in the data­base, too. This per­mits the nav­ig­a­tion to be dynam­ic­ally gen­er­ated. Links to external sites (or static files on this server) are stored, too. One change will res­ults in easier man­age­ment. Also stored in the data­base are any bin­ary files: images, PDFs and ZIP files.

Why dynam­ic­ally build this site? It makes it much easier to add ele­ments on the fly, without hav­ing to change and upload many static files — which is espe­cially the case with nav­ig­a­tion ele­ments. Nor­mally, if you add another sib­ling page (a page in a dir­ect­ory that is related to the other pages) — you have to update all pages in that dir­ect­ory to reflect the new entry. I believe that nav­ig­a­tion gives you, the user of this site, con­text. So keep­ing this syn­cronised is important.