Shelter

Tech, philosophy and random musings

24 June, 2008 by Alex

Thoughts on PHP

Yes, yes, I admit the herasy; I like PHP. No, no, PHP has tons of worts with it, so no, it’s not better that alternative X, Y or Z for task Q, W or E. I hate comparing languages this way, feature by feature, syntax by semantics, and so on. I like to judge languages on two things;

Environment

I really like the CGI style for web resources. No, PHP ain’t CGI (unless you’re in a pain-self-inflicting mood) but most often a glorious Apache module which reuse all the goodness it can offer, but the model of a totally independent scripting engine which needs to mold its relationships, and then you throw it away when you’re done, makes for a clean, fast and very scalable framework. PHP basically compiles together mostly C modules, and use its simple syntax to glue stuff together. Yes, there’s a backlog of really shitty and badly written code out there, especially when people have no clue. And when the threshold is as low as it is for PHP, that’s inevitable, but I hardly hold that against the language itself. The environment in which that shitty code runs is really good. To me, the environment is the best part of PHP. Perl falls somewhat into this same category.

For those in the know, this model is very similar to how a RESTful system works, where the interpreter is a manifestation of a resource. In resource-oriented development this means gold, and is very important to me as my environment supports my RESTful way of designing systems.

Style

And since style is something any good developer can control themselves (unless their language is super-strict), this really is the main thing that I like about PHP; It gives me the freedom to make things work for me. I can choose the methodology, whether a function, class or inline is best suited, and since PHP always is evaluated in run-time, I can make my environment depend on real-time parameters rather than a pre-compiled utopia.

Zend Framework

I’ve been using the Zend Framework for the last year or so, and it’s a great framework as such, although the focus has been mostly to put OO wrappers around common PHP idioms and conventions. As such it works great to perhaps consolidate the features, and perhaps give PHP 6 a future direction. This is the best part of the Zend Framework.

The bad thing about the Zend Framework is that it imposes its own style, and somewhat alters the environment. Ouch, on both the things that make PHP my choice tool. I’ve struggled quite a bit in trying to reuse certain parts of the framework, extend others, and generally use some bits without using the whole shebang. There’s not a lot of dependencies between the components, but just enough to make it tricky to do serious stuff (for example writing an alternative “threads-like” HTTP adapter to HTTP Request).

Now, people talk about the Zend Frameworks impact on the future of the PHP language. Yes, one can always hope that this is the case, but I think people are a little too preoccupied with the OO capabilities and forgetting perhaps what makes PHP really popular with those who choose to continue to use it past their first few applications. Do not fall into the trap thinking OO is somehow better than other ways.

As much as people think MVC is the best thing, I really don’t care about that. MVC works great for some things, not for all (for example, I have a REST framework that use a completely different model, a more resource oriented model), so to impose MVC as the modus operandi is not good, and indeed something that makes reuse of other ZF modules a bit trickier. Instead of a MVC focus, there should be a strong highlighting of a uniform interface to the environment itself. It’s the environment that’s cool with PHP, so let’s make interfacing to that better. There’s some work on wrappers and readers for various aspects of the HTTP protocol, but only the most basic stuff is in there and needs serious work. With PHP I could do serious HTTP applications; with Zend Framework I’m limited, and need to hack and extend. Let’s get HTTP savvy, not MVC drones.

Availability and diversity

PHP is everywhere. Period. I can use pretty much any ISP or in-house hosting to host most of what I need. And there are so many different open-source projects about that uses PHP (WikiPedia, WordPress, PHPBB, PHPMyAdmin, Drupal, Joomla, Flickr … the list goes on) meaning both hosting and the amount of high-quality tools are abundant. The LAMP stack is pretty much supported on every hardware and software platform. Heck, I can even run it on the JVM.

I have written many tools over the years, some good, some bad, but I’m always happy to find out that I can copy my old files into any new environment and they will pretty much always run straight away, no tweaking. I can’t tell you how important this is!

The shitty stuff

No system is perfect, to some specific definition of what “perfect” means. With PHP, I’ve learned to live with its odd bits, such as funny booleans and comparators, diverse and non-uniform APIs, sloppy exception handling, no shared memory (which may or may not be a good thing, but certainly a big part of its design), and a few syntactic snuffs (Why not introduce “$$” as a shortcut for “$this->”, for example? Tidbits).

Some say that PHP code is crap, usually said when encountering – indeed! – shitty code. But shitty code is everywhere. Even in the most tied-down, static and controlled environments you still get shit. Some say less shit. I say shit with a different color, not different odor. I’ve been programming for almost 30 years soon, and let me tell you, I’ve encountered shitty code in every single environment and language I’ve ever tried, and I’m one of those who tries every language out there. There is no language who can hold a stick to the wonderful imaginitive mind of man, able to lay bricks where diamonds should have shone.

Some say the PHP language itself is immature, or unstructured, or some other parameter that their favourite language holds. No, sorry, but there’s not that much which separates all our different languages (except BrainFuck … that one is seriously different. :), and indeed a lot of the language wars are really more about their API designs than the languages themselves. For example, the syntax of Java is tolerable, but a lot of its APIs are not. The syntax of Python is ok, but some of its APIs are great. Ruby has good syntax, but to me some confusing APIs.

It’s really mostly about APIs, and how we create models to solve our problems. It’s all about models, as APIs in themselves are models. The API is not the language.

Round off

I should here of course mention the link between models and Topic Maps, as the latter is a way to define, work with and exchange / share the former. Couple this model openness with resource-orientation, and I think it makes for a very interesting environement. But as this whole shebang is part of the new framework I’m working on, expect more blogging on this in the very near future. Have a wonderful week.

Filed Under: Application Design, Php, Soa Roa Woa Rest Soap Ws Architecture, Topic Maps

7 September, 2007 by Alex

REST and SOA as a process for application design

I’m going to stray a bit from the library theme, and talk about design of RESTful SOA. It’s a topic close to my heart, as most SOA talk these days are full of vendors claiming money can buy you not only love, but immortality. With SOAP? Hah!

No, I think reinventing what the Web does really well already is a) a waste of time, b) doomed to make a bad copy (as the web is constantly moving, while the SOAP / WS-* stack is immersed in slow-moving standards), and c) over complicating things (I like elegant simplicity such as the innards of the Web).

REST

Roy Fieldings’ REST dissertation has swooped upon the middle and higher layers of the IT world lately, making a lot of them admit that, perhaps, this whole deal about using HTTP and loose XML (often XHTML) to create scalable, fast, simple and dynamic applications (well, as an architectural style, to be specific) might have something going for it. REST has been around for a long while, being the very fabric of what the internet is based on, slowly extended and refined over the last years 15 years (even though a lot of these concepts are again based on earlier technology).

Service Oriented Architecture (SOA) is a little bit tricker to define, especially these days when big corporations have discovered and use it as a buzzword, but basically it is technical architecture creating loosely coupled (meaning; the items in question knows very little of each other) services, and where a service is a piece of software that some other piece of software might use (as opposed to direct human usage). Now, a lot of people already talk about this stuff, so I’m not going to add to that. I’d rather talk about what I think when I do this stuff, to talk about actual implementation.

Working in both these two worlds, putting them together to design and create applications, is quite different from the normal software development processes that’s so popular these days. The most striking difference is that during application design you think in terms of resource orientation (as opposed to object orientation, or functional design) and how to represent services (as opposed to a program, or a module).

You can either plan a big-bang approach to this (standard waterfall models) per service, or you timebox a more agile approach of creating one or several services that does the simplest thing needed to service your proposed application. The world spins around the axis of identifying application to solve problems; let’s turn things around (and this is a big part of SOA) and see if we can come up with services that solves problems instead.

Typically you have a sleigh of applications that all have common functionality, such as user management, database storage, configuration, session handling, search and a few other bits and pieces depending on the business you’re in. There’s many ways to deal with reuse of these “things”, and I deliberately call them “things” at this stage, because as soon as you call them “modules”, or “libraries”, or “reusable code” you’re setting the scene for quite implementation specific stuff, such as what language you’re going to use, or what platform it runs on. I don’t want to deal with “libraries” for example, because if some library is written in Java then I need to make my other solutions in Java, too. If I have a “module” that does X in Windows using C#, the chance that “module” is linked to that technology is quite high.

Things

No, I want to talk about “things”. For example, let’s talk about users. A lot of applications deal with users in some way or another, whether it’s displaying information about them, for them, authenticating them, create properties on them, or otherwise work with their user data. How can we create a service that applications might have good use for?

Since we meddle here in all things REST, the first thing we do is to think of the service in terms of resources (as being resource oriented is extremely important; expose URIs for every resource, as small / atomic as need be). I usually create two sub domains to hold services, one for internal behind the firewall services (soa.domain) and one external (ws.domain; ‘ws’ for web services), and I also try to have a trim set of basic elements that express generic functionality (search, user, session, database, properties, etc) wrapped in an even smaller and more generic set of domains (x, y, z, a, o, a, etc.). Through this, the first part of my design process is to play around with URIs and hierachial taxonomical ideas to see what feels right ;

http://soa.example.com/identity/user[/{userid}]
http://soa.example.com/user[/{userid}]
http://soa.example.com/user/id/[/{userid}]
http://users.soa.example.com/{userid}

Balance this with ideas on premature optimization (what, you thought that was axiomatically bad? It’s allowed to think about these things, you know 🙂 in terms of request times for a domain (the more domains involved in a series of calls, the longer the overall response time, generally speaking) and what feels right.

In my case, the first one seemed the most right. I’ve developed a small set of root categories in which I “place” my services, such as /search, /publishing, /identity, and so on. These categories are not canon; they are placeholders for loose ideas and thoughts, bound to change in the future as your SOA evolves.

Evolution

Evolution in your SOA is very important, so you should design for it in mind. For example, what about version control of services? Some talk about versioning being part of the XML schemas that services deliver, others talk about content negotiation (crazies :). I take a rather pragmatic and somewhat naughty approach (in the sense that you shouldn’t put semantics in your URL’s which humans will look at and try to pry apart and use / misuse) and put versioning into the URL at the base of the service defined. For example ;

http://soa.example.com/identity/user/v1[/{userid}]

I also set a rule to service development ; maintain backwards compatibility as far as you can. There’s no need for an ever update to the version number if you design your XML schemas that pass through them in smart ways, and this reduce the overhead of deployment, introspection and dependency. Another rule to service digestion is to only react to what you understand, and ignore all that you don’t; this again enables backwards compatibility as you, say, add a new (but non-critical) element to your metadata which older service users don’t understand and simply ignore.

For proper development of a RESTful SOA, though, I’d suggest two things as a minimum ;

  1. use test-driven development for the service definitions (and use whatever methodology you like for the actual code for the service, although test-driven there too won’t hurt you), so write your tests for your service (I use XPath with XSLT scripts for this) first and then develop the actual service until it passes all tests, and
  2. collect your services’ tests into a large test suite ; whenever you add, subtract or change a service, make sure all tests pass. (If you can sneak this into a build farm of sorts, all the better. Automation for this type of development will probably save a lot of gray hairs) Through this you know what breaks and what’s backwards compatible with your changes across the whole SOA. Don’t deploy anything from development into test or production unless all tests pass. This is not a trivial task, and should be in the hands of someone who is full-time responsible for the SOA’s well-being.

Now, in evolution of SOA’s as well as in nature, don’t be afraid of screwing things up. We don’t want perfection. We will never get perfection. And we certainly won’t get anything near it in the first go. All these services must be allowed to change over time, dramatically at first, even to the point of deleting it completely, and start from scratch making something different. (In fact, I’d advocate making all these first-generation services with version number /v0-ALPHA/ in all caps, as in http://soa.example.com/identity/user/v0-ALPHA[/{userid}] ; this will mark them as experimental and trigger other developers to tread gently. If they worked great, just update them to a /v1/ version)

Time management of this development is also important. Because services must be allowed to break, be allowed to screw up, we must also allocate time for these screw-ups to happen. Trust me, it’s a good thing ; a smaller failure now ensure we don’t screw up big time later. (And this very point is probably the cause of so much bad management and so many failed [enterprise] projects as it’s very easy to overlook or not taken seriously enough. I can write a whole book on this topic alone!)

And people who have some sort of ownership of a service (as developers, or analysts, or whatever) must be given time for short iterative development, for little updates, modifications and tweaks. Services won’t be successful if you treat them as small bangs (meaning; gather requirements, write spec, make it, sign it off), and probably only can work through continuous tinkering. Such tinkering doesn’t have to be time-consuming nor difficult to manage, but it does require you to plan for it. When Bob goes on to his next project, remember that he’s also needs a half-day per week to tweak and fiddle with his service.

Introspection

One feature that I can’t emphasize enough is service introspection, an area that most writers I’ve seen gloss over. And sure, you don’t need it in order to create a SOA or a web service. But I’ll assert that you need one if you’re a) smart and b) want to create a healthy SOA that can stand the test of time.

Introspection in my world does three important things ;

  1. Handle the client state through hyperlinks (part of the REST paradigm)
  2. Documentation of interface, use and dependencies
  3. Provide test suite

Asking a service for introspection in my world goes something like this ;

http://soa.example.com/identity/user/v1?introspection

or, if you want to split the three up ;

http://soa.example.com/identity/user/v1?introspection=state
http://soa.example.com/identity/user/v1?introspection=docs
http://soa.example.com/identity/user/v1?introspection=tests

1. Handling state of a client through hyperlinks is a somewhat forgotten part of REST, which is easy to miss when your design is at an early stage (and it usually stays that way because you don’t think you need it by the stage you’re made aware of it). It basically comes down to either URL-driven or FORM-driven hyperlinks that takes you from whatever state the current URL gave you to the next one. For example, a resource soa.domain/search?q=fish might give back a list of URL’s to pages of results, or a form to do a sub-search, all documented through hyperlinks. I personally think the use of XHTML is good for this, but a bit more formal and equally elegant is the use of the Atom Publishing Protocol (not to be confused with the Atom Syndication Format).

2. Documentation is important, and could be as easy as just returning an XHTML page with some text about what it is, how to use it, and so forth. However, I see a major part of documentation as to what dependencies the service has got, so I’ve got a section that looks a bit like this ;

<ul id="SOA-dependencies">
<li><a href="http://soa.domain/some_service/v2">Some service</a></li>
<li><a href="http://ws.google.com/wdsl/service/1.0">Some Google service</a></li>
</ul>

Notice that this is perfect XHTML. All that’s required to understand this list is understanding the identifier for the list, the “SOA-dependencies”, which I can locate easily through DOM or XPath. Through this mechanism in services you can now map the whole dang thing, plot in your dependencies, check it against your test suite (talked about earlier) for ultimate coolness and power.

In this section I might add that I often incorporate a ping parameter which testing and monitoring systems can use to check the health of a running SOA, something like ;

http://soa.example.com/identity/user/v1?ping

or, if you’ve got the RESTful chutzpah required, use the HTTP method OPTIONS instead of a GET on a URL. I actually do both. The HTTP response code hence talks about the generic health of the service as far as it knows, and you can use this info not only for monitoring and testing, but also for automatic systems and smart clients.

3. It may seem a bit strange to ask a service to give you a test-suite, but it actually is a very encapsulating and clever thing to do, making sure that tests are all handled at the same place where development takes place. I can do ;

http://soa.example.com/identity/user/v1?introspection=tests

and I’ll get back something like this ;

<testlist>
<test name=”My first test”
href=”http://soa.example.com/identity/user/v1/2456325786234985″
xpath=”/response/item[@name=’user’]/id”
is-true=”2456325786234985″ />
… [more tests here]
</test>

Basic test-case skills are probably a plus at this point to understand what this is about, but basically we assert that the XML/XHTML that the URL returns will give the result “2456325786234985” when the XPath expression “/response/item[@name=’user’]/id” is run.

Your testing framework for the SOA simply collects these test files at intervals to build a larger test-suite that stands as the controller for the whole system.

Finally

Just a few finishing thoughts about rigidity, complexity and management of a RESTful SOA ;

If you don’t have dedicated SOA people, then don’t do it. If your people (developers, analysts, managers) aren’t very flexible, then don’t do it. If you don’t understand REST, either really learn it (this book is the best there is on this subject!), or don’t do it. If you think you need complex systems, don’t do it. If you can’t wrap your head around resource-orientation, then don’t do it.

The thing is, you can perfectly well live without it, create SOA or some other well-meaning version of that concept with SOAP/WS-*/BPEL/ESB or whatever big vendors are more than happy to help you with. You can create POX services just fine. You won’t be RESTful, but you will probably survive without it. You don’t need it in as much as you can live on only water and bread for years and years, but of course I wouldn’t recommend it. 🙂

Anyways, a few thoughts there on RESTful SOA design and implementation. I haven’t digged into the semantics of modeling a full SOA yet, nor talked much about pipeline XML schemas (although the APP protocol is a good hint), system introspection through things like WADL, or even the hidden benefits of ROA (resource-oriented architectures). So. More to come, then. Until then, happy hacking.

Filed Under: Application Design, Rest, Soa, Test Driven Development

11 June, 2006 by Alex

Designed by stupidity, built by ignorance, approved by incompetence

Note: I wrote this piece back in 2006, and just scrubbed it up. Enjoy.

“Stupidity” from Wordnet:

– a poor ability to understand or to profit from experience
– a stupid mistake

Design is the process of taking a set of constraints, and make something out of it. These constraints can be a number of things, from trivial wishes to strict rules. Sometimes it’s about a color, other times about functionality, and then again about its basic concept, maybe a marketing angle or perhaps changing some stuck process. It could be anything.

However, a lot of the time you’re left with that compelling feeling of “Qua?” while reading through your constraints; he wants me to do what!? They think we should put in that!? She likes what color!? marketing wants to sell this to whom!?

One definition of something stupid is when you can’t see what is obvious to others. Sometimes this can have as much to do with your definition of a problem as a personal viewpoint, but quite often this “stupidity” certainly points to things we overlook or just plainly can’t see but what we certainly should address.

Good design is about seeing things from as many angles as possible, and find the best possible compromise between them.

“Ignorance” from Wikipedia:

Ignorance is a lack of knowledge, or a willful lack of desire to improve the efficiency, merit, effectiveness or usefulness of one’s actions. Ignorance is also a “state of being ignorant” or unaware (not knowing).

Building systems (applications, processes, buildings, societies, anything) is a complicated thing, relying as much on the goodness of the designers as the intelligence and skill of the builders.

Some people willfully ignore things. Maybe they feel they know enough, or maybe there are fears involved. Whatever the case, you see it all the time; people walking on a red light, smoking where not allowed, slightly speeding while driving, daydreaming while in meetings, outsourcing for the sake of instant capital gains, eating unhealthy food, not practicing what you preach, ignoring global warming signs, keep investing in oil consumerates, draw red buttons for safe functionality, never test your assertions and so on. The list is endless. People ignore things because of the normally low frequencies of events.

When builders ignore the time effects on setting concrete and make a too thin layer for your foundation, a layer without skeleton, and a few years down the track the building may simply collapse. If you don’t fully understand the difference between alcohol and methanol it just might be the difference between life and death. If you ignore warning signs, whole cities might be flooded, or buildings blown up, or kids will use guns on other kids.

Good design is to preempt what warning signals has taught us.

“Incompetence” from Wikipedia:

Incompetence is the condition of a person who is unable to properly perform his assigned duty. Incompetence is the essential ingredient of the Peter Principle, which states that in a hierarchical organization, every employee tends to evolve through promotions towards a position in which he is incompetent.

Approving systems tends to happen after it has been built as opposed to something that happens in parallel. That being a flawed strategy from the beginning I guess is hard to overlook, but let’s focus more on the common way we approve the systems we design and build.

First, approval is mostly a binary thing, no matter how much history teaches us otherwise. If it still is running and does what it says on the tin, that’s considered a success, even if you don’t fully understand why it was written on the tin, nor what the tin was supposed to contain or should contain.

Then there’s approving things because your job is to approve things instead of guiding things or cancelling crap things. If you and your team spent months on a project you’re not going to be self-reflective enough to call yourself out in public.

Good design is to allow for failure.

To shift things around

In order for us to shift things around when they are going pear-shaped (hang on, what’s wrong with pear-shaped? I love pears, and I love pear-shaped women, what gives?) we must focus a bit harder on design from the middle principle. I’m a bit tired of both top-down (we know upfront all there is to know) and bottom-up (we know only know so little) approaches. Could we please start somewhere in the middle, and work ourselves out from there? Thanks.

Filed Under: Application Design, Business, Ia, Ux

Recent Posts

  • Another bob
  • Another tidbits
  • Philosophical and religious matters
  • Do libraries understand the future? Or how to get there?
  • Before I write what I write before the next time I write

Archives

  • April 2010
  • March 2010
  • February 2010
  • December 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • January 2009
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • September 2007
  • August 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • January 2007
  • December 2006
  • November 2006
  • October 2006
  • September 2006
  • August 2006
  • July 2006
  • June 2006
  • May 2006
  • March 2006
  • October 2000

Categories

  • Alsa
  • Application Design
  • Australia
  • Baroque Music
  • Biology
  • Blogging
  • Book Review
  • Business
  • Canberra
  • Chemistry
  • Coaching
  • Communication
  • Conceptual Models
  • Conference
  • Context
  • Cooperation
  • Cosmology
  • Creationism
  • Crows
  • Cute
  • Data Modelling
  • Data Models
  • Debt
  • Dune
  • Ead
  • Ecology
  • Elegant Code
  • Emnekart
  • Environmentalism
  • Everything
  • Evolution
  • Family
  • Film
  • Food
  • Frameworks
  • Fstl
  • Future
  • General
  • General Life
  • Globalism
  • Grace
  • Happiness
  • Harmonica
  • Holidays
  • Humanity
  • Ia
  • India
  • Indiana Jones
  • Intelligence
  • Java
  • Jobs
  • Juggling
  • Kiama
  • Kids
  • Knowledge Representation
  • Kuala Lumpur
  • Language
  • Laptop
  • Leipzig
  • Library
  • Life
  • Life Lessons
  • Linux
  • Localivore
  • Lucas
  • Marcxml
  • Misc
  • Monteverdi
  • Mood
  • Movies
  • Music
  • Music Production
  • Norway
  • Ontology
  • Ooxml
  • Open Source
  • Oslo
  • Oslo Domkor
  • Oss
  • Philosophy
  • Php
  • Planning
  • Programming
  • Programming Languages
  • Proud
  • Rdbms
  • Real Estate
  • Rental
  • Rest
  • Richard Dawkins
  • Salut Baroque
  • Sam
  • School Closures
  • Semantic Web
  • Semantics
  • Soa
  • Soa Roa Woa Rest Soap Ws Architecture
  • Sound
  • Spielberg
  • Status
  • Stupidity
  • Systems Thinking
  • Talk
  • Technology
  • Terje Kvam
  • Test Driven Development
  • Tidbits
  • Tmra
  • Tmra 2008
  • Topic Maps
  • Ubuntu
  • Ubuntu 9.04
  • Ucd
  • Uncategorized
  • Universe
  • Ux
  • Vista
  • Wollongong
  • Work
  • Working From Home
  • Xml
Copyright © 2021 Shelter.nu