Saalon Muyo

Would you like your friends to see how you’re doing in NaNoWriMo without having to look at a page other than your truly awesome blog?  Well, I’m here to tell you how to do it the wrong way.

You heard that right, people.  This is not the right way to do it.  I mean, it works.  You can see that on the side of the page.  But it’s a hackity hack.

If you feel like putting more than 15 minutes into the entire process, you can come up with a better option.  But if not, just drop this into your sidebar.

One note: Dreamhost doesn’t let you use the php file() method to get external URLs by default, so there’s a little hack in there to turn the option on, then turn it back off.  If you’re not on Dreamhost, this may not be necessary.  The methods to remove are the init_set() methods.  Just so you know.

<?php
// Allow file() to open urls.
ini_set('allow_url_fopen', '1');

// Replace the url here with your own NaNoWriMo API url.
// Just log in, go to Fun Stuff->Word Count API and you can get it there.
$result = file('http://www.nanowrimo.org/wordcount_api/wc/418267');

// This is the hack part of the hack.  The results come back in an array,
// and I hardcoded the correct index for the word count.  There is probably
// a better overall way to do this. I don't care.
echo("I've written " . $result[10] . " of 50,000 words.");

// turn back off letting file() open urls.
ini_set('allow_url_fopen', '0');
?>

Am I missing something here? ’cause it sure looks like an “or” would have served this better than an else if.

                            if (tokenInfo.IsParentCalculation)
                            {
                                LoopTableSave();
                                GetValue(tokenInfo.Id);
                                LoopTableRestore();
                            }
                            else if (tokenInfo.AliasOf != 0)
                            {
                                LoopTableSave();
                                GetValue(tokenInfo.Id);
                                LoopTableRestore();
                            }

A big part of my job is working with these third party business software packages.  They call them ERPs: Enterprise Resource Planning applications.  They’re basically Quicken on steroids, allowing you not only to Balance Your Budget  but also Track your Inventory and possibly even Forecast The Future!  They’re the little brothers of those monstrosities you see at big corporations like Peoplesoft, but they pretend to do everything the big guys do, meaning they do a crappy job at everything.

The Face Of Evil

You might be able to guess that this is by far the favorite part of my job.

What I need to do sounds simple.  Our software receives a purchase order, which we need to shove into our customer’s ERP.  Then, when they invoice or ship, we need to rip those documents back out of the belly of the beast to send on to their partner’s.  We do some other stuff, too, but let’s just focus on the basics.  Shove in, rip out.  Repeat.  A lot.

That it sounds easy should tell you that it’s not.  The science of API design is, in my eyes, still feeble.  That may be changing with a lot of the really interesting web APIs being build by Google and Yahoo and Twitter and whoever else, but on the desktop side APIs and SDKs are afterthoughts.  They’re added when executives realize, late into the game, that an application which someone can Program At may sell better than one which can only be used through the buttons visible through its UI.  It’s then implemented by programmers, who have built an application whose buttons may not do their desired tasks as it is, in the fastest fashion possible.

Then, at some point over the next year, they start trying to fix it, at which point it simultaneously gets better and worse.  Better because it starts technically working,  but worse because there’s rarely any way to tell which of the vaguely named methods do what, and because strange new forks in the road get taken midstream, giving the API a case of schizophrenic maturity.  Small sections of the API, the ones people have been bitching about, get tons of attention and work perfectly, while similarly structured but different sections of the API appear to be the same but, in practice, are not.

ERPs are now required by Business Mandate to have some kind of SDK/API, but their dedication to the utility of these tools varies wildly.  They all have the gloss of professionalism, but under the hood is where the nightmares begin.  My favorite, by far, is the SDK of SAP Business One.  Its SDK contains two wonderful pieces.

Ugly, But Seriously Less Evil

One is the DI-API; the Data Interface for the system.  This is what you’d use to integrate with the system from an external application.  It’s what we use in most cases, and while we use it for SBO, we don’t use it for everything.  Which is too bad, because while it’s twitchy and crappy, at least once you’ve got it working it functions.  Oh, sure, they decided to build it so that it’s child’s play to update the client software without updating the SDK, leading to confusion and frustration when the integration “suddenly” breaks.  But other than that you can, you know, shove things in and rip them out.  No big deal.

No, it’s the second piece that is the true star of the ERP Nightmare Circus.  It’s the UI-API; the User Interface API.  On, how the fun begins.  They have something like three ways of building forms, none of them great.  One is driven off of XML.  Another uses an add-on called Screen Painter which, at the time we developed the solution, didn’t work. Finally you can just build the forms through the code.  Or if you’re like most developers, you can mix and match wildly.  Fun!

The UI-API allows installed add-ons to block events from reaching other add-ons.  This is one of the best features, allowing developers to accidentally break each other’s add-ons with gleeful abandon. What’s best is that nothing errors out, exactly.  Things just stop working.  To sweeten the pot, SAP also offers no Add-on compatibility testing at all, so someone selling these add-ons has no idea if they’ll mix safely unless they test them on their own.  You can imagine, I’m sure, the joy in customer’s voices when two things they paid money for break their entire system.

This is in addition to the kind of shoddy documentation and barely useful testing tools that all APIs come with.  And I shouldn’t complain too much: the SDK for our software is worse, since it’s still stuck in the “We should have it” phase without having moved onto the “We really need to fix this now” phase.  We’ll get there.

Though, since I’m being mean and calling SBO out I should give credit where credit is due.  While still a bit buggy, the SDK for Everest Advanced is shockingly good, with OK documentation and a test tool that really saved my butt while I was developing for it.

And I’m still looking for a good, dirty riff on ERP.

I’ve spent the last few weeks driving around a Lexus for the first time, and I’m not exactly sure what to think about it.

On the one hand it’s very powerful, in the sense that it permits you to code your entire website as if it’s an application and not html.  Every page has a CodeBehind page that lets you work in the exact same way that you would on a desktop application.  And the HTML side of the page barely needs any HTML at all.  In fact, you can get away by using ASP.Net controls almost exclusively, including for such simple things as links and images.  And those controls, by default, will just post back to your codebehind page, just like wiring up events on a GUI form.

I can see why ASP.Net developers like it.

On the other hand, it completely ignores all established web development conventions. The very things that make it nice for a lot of developers are what make it a poor fit for web development if you use it in the default fashion.  Many of the things which make ASP.Net convenient fly in the face of the way you’d do development on any other platform.  To many, I’m sure that’s a good thing.  It’s easier to set up an ASP.Net control, set runat=”server” and just catch the OnClick event in the Codebehind and do your thing than it is to learn how to set up an HTML form and learn to set the form’s Target, give it a submit button and make sure whatever page is the target has code to catch a form submission but do something different when it’s just being hit directly.  I get that.

But the way ASP.net handles a lot of this just outright breaks things that would be otherwise simple.  First, a primer.  ASP.net controls are, in essence, pieces of .Net code that get rendered by the server at page load and turned into html at that time.  So while your page may have an ASP:LinkButton for your link, when it gets sent to the broswer it’s a straight link tag.

But let’s say that LinkButton has an ID that you want to reference through Javascript on the page, and that ID is “submitLink.”  You build your Javascript to reference “submitLink” only to have it error out because no control with that ID exists.  Huh?

Turns out when ASP.Net renders your Linkbutton into an html link it also changes the ID, so now what you’ve got is “ct100_LinkButton_submitLink.”  But you have no way of knowing what that ID is going to be until you load the page and look at the page source.  So if you want to do any Javascript or CSS that references control IDs, you have to load it in a browser and rip the IDs out of that.  What concerns me further about that is, if the ID is generated dynamically, how can I be sure some change to the code won’t screw the ID up and break my Javascript?  So far, I haven’t found an answer to that question.  If there isn’t one, that’s a bigger problem than just an inconvenience.

Now, you can use regular HTML with ASP.Net and create rational webpages with it.  It’s not a broken platform, exactly.  The problem is that because these Desktop App style crutches exist, people use them when they shouldn’t.  The site I worked on is filled with ASPisms that, on reflection, bother me a lot. Pressed for time and lacking experience, I fell back on those crutches because they were the closest tool that could get the job done.  I think one day I’m going to pay for those choices.

ASP.Net feels like a web development platform designed specifically for the Visual Basic coders of the 90’s.  People who have a low tolerance for new ways of doing things and little interest or ability to step outside of their comfort zone.  It’s web development for non-web developers.  It lets you build a desktop application that shows up in someone’s browser.  At least, its default configuration is.

What that default configuration leads to is a lot of programming that works fine in desktop applications but is clunky and slow over a network.  ASP.Net promotes inefficient web code by allowing you to work within parameters that aren’t optimal for the web, and giving you all the tools you need to stay there forever.  We have an internal website which is terrifyingly slow for what little most clicks do, and most of it can be tracked back to ASP.Net letting our developers build it as if it were a desktop application.

You could do some excellent work in ASP.Net, but I believe that by doing so you are probably avoiding many of the things that were the reason you chose it in the first place.  I could avoid using ASP.Net controls and do things in a more purely HTML way, but that’s just breaking the paradigm Microsoft set up.  If I’m going to do that, I’ll use a platform that was built to integrate with HTML more naturally.

I understand the world ASP.Net is meant to live in.  I just don’t like it all that much.

I’m not a big podcast nut, but I’ve become hooked on the Stack Overflow podcast recently.  It’s done by Jeff Atwood of Coding Horror and Joel Spolsky of Fog Creek and Joel On Software as they work on their new programming message board/wiki/Knowledge Base project, and it’s pretty good.  It’s good even if you, like me, find Joel somewhat annoying in the way that he seems to pick fights just for the sake of it.

Brennen has referred to Joel as a professional troll before and at times like this I have to agree.  On episode 13 of the podcast, Joel - seeking and succeeding to inspire posts like this - analogized ASP.Net to driving a Lexus SUV and PHP to riding a bicycle.  This was to illustrate his claim that ASP.Net is a generation beyond PHP in power, functionality and, I suppose, status amongst the soccer MILFs you may want to hit on.

I’m not going to get into this too far, mostly because it’s a silly comment that has no basis in fact (though ASP.Net does come standard with air conditioning and leather interiors), but also because it’s a worn out, circular, boring topic.  Use whatever platform works for you.  Get your project done and meet your own requirements.  I only want to say one thing.

You may want to be careful with your analogies, lest you come up with one which can be interpreted thusly: So what you’re saying, Joel, is that ASP.Net is inefficient, uses up limited and expensive resources and is purchased more often as a badge of economic success than because it’s actually the best car on the market.  And PHP is the world’s most efficient method of locomotion, destined to become the new standard of transportation once we’ve gone broke keeping our Lexus SUVs running.

Did I get that right?

Two web projects kick off at once, leaving Eric reeling!

I’m about to begin two - yes, two - web development projects, and I’ve never build a website in my fracking life. One is for work and the mockup has to be done in a week and a half. The other is for a new project which I’ll discuss in detail later, which doesn’t need to be up for another month or so but is going to be a lot more work. I’m a little scared.

This is just a beg for wishes of good luck.  I’ll see you all on the other side.

Maybe newly jobless.

Ha.  Ha ha ha.

Having mastered application development in every conceivable way, I have decided to demonstrate my superior coding abilities to the world through the World Wide Web.  I know it won’t be a challenge - what possible challenges remain to one such as myself? - but it will allow for a higher ego boost::work ratio than this piddling .NET client software nonsense.

Ok, now that I’ve gotten fantasy out of the way, let’s talk a little bit of cold, sad reality.

First: I’d be happy if I mastered sanitizing user form input.  I’ll be mastering client-side application development right around the time when someone invents the warp drive.

Second: I can’t blame anyone for using PHP.  Because I’m going to.

I’ve decided that it would be in my best interest to know how to do web development, since that’s probably the future of most available programming work out there and it’s also the most likely hobby-coding I’m likely to do.  I rarely think “Damn, I wish I had the skills to build that Enterprise Java Application,” but come home every day and bemoan the fact that I don’t know where to begin on simple websites to host creative projects.  My hacking must serve my writing, and that means web development.

Brennen hates PHP a lot, and I can’t argue with any of his reasons for hating it:

1. The culture produces sloppy, unreadable code.
2. The language is often inelegant and sometimes downright ugly
3. It encourages bad design practices (see problem 1)

On the other hand, I put up my first, test web form with pointless-but-effective actions in about 30 seconds of coding with no configuration goofiness.

I hacked around with Python - a language I love very, very dearly - in the hopes of doing a web project based in it, but the prospect of screwing around with CGI, WSGI, flup, web.py and whatever other framework nonsense it demanded was starting to make my brain swell.  It might be a fantastic platform once you get things going, but I had to get things going and as I still have to learn an awful lot of other web-related nonsense first…well, let’s just say I’ll worry about Pylons and Django when that’s the only other thing I have left to learn.  And even then I’m not sure it’s worth the overhead.

The point is, Python is a way better language than PHP.  In fact, I don’t think I enjoy coding in any language as much as I enjoy working in Python.  It’s clean and lovely and has simple to use language structures that make working with common things like lists not a complete annoyance.

But language elegance doesn’t matter if deployment is a bear.  Deployment sucks under the best of circumstances, so adding on additional deployment nightmares and the possibility of things just not working when I have to move to a new server so I can type:

for item in list:
    print item.Name

instead of:

for(i=0; i < list.length; i++)
{  echo list[i].Name; }

may not be worth it.

And anyway: PHP still beats ASP.Net any day of the week.  Then again, if John Stamos were transmuted into a web development platform, it would be better than ASP.Net, too, so that’s not much of a comparison.

I’m finding that my writing process and coding process is more similar than previously imagined. This shouldn’t be a surprise. I’m not the only one that’s gone on and on about the similarities between artistic and design processes. Maybe it isn’t really a surprise, or a revelation, but an unexpected clarification.

When I write, I spend most of my time thinking and not writing. My actual time spent putting words onto electronic paper is minimal compared to how long I spend pacing around my office moving pieces around inside my head. In fact, when I do it right, the actual writing part of writing is as close to effortless as work can get. That’s one of the reasons I don’t like to write before knowing what I’m writing; when I do, it feels too much like work. The other reason is that I hate editing. I’ll talk about that later.

I’ve now worked on a handful of end to end projects in my engineering job, which is enough to start noticing patterns. I’m finding (shock) that I spend a very long time organizing the overall picture of what I’m doing in my head (or sometimes in a notebook) before writing more than a few liens of code or defining a few empty methods. It leaves me feeling unproductive for the early part of my project, as well as afraid I wouldn’t finish on time. How was I going to get the coding done with half of my time already spent?

Yet in every case, once I had a good model of what it was I was doing, the actual coding part of the project only hit a snag if I needed to figure out how to technically implement something. Like this: I know I want to find this part of an XML document, but I don’t know the correct method to accomplish it. I also was spending much less time than expected having to debug what I had built, both because I had worked out a number of the logic problems before coding, and because the time spent thinking had produced relatively clean code that was easy to fix.

I doubt I’m the only person who uses a long Thought Before Code spin-up process, or even that I’m in the minority. At least, I doubt this is a rare practice amongst successful programmers. The unsuccessful ones rarely have consistent processes, which is probably what makes them unsuccessful. Still, I wasn’t expecting such a clean similarity between how I write stories and how I write code.

Then I thought about it further, and it makes a kind of sense I should have seen before. When I go through my writing spin-up, it’s not the language or the flow of a conversation that I work out before writing. It’s the way the larger, more abstract pieces are going to interact. It’s how the motivations of a character are going to bounce them into or off of other characters, how all of those characters are aligned in such a way that what results is a clean, smooth narrative.

What I’m working out are all of the pieces that must exist behind the story for it to be the thing that I see in my head. The delicate connections between this strand and that, between event and response, between motivation and action. It’s a kind of architecture, really.

When I was in my first photography class, my teacher described the most important part of taking any picture: pre-visualization. Don’t press the button, he said, until you can see the picture that will result in your head. This wasn’t just looking through the viewfinder and lining up the framing or pulling focus or deciding how far to zoom. It was more than that. It was visualizing the way you wanted the picture to look by understanding how the camera would see the scene.

A photographer needed to put himself inside of his camera. They needed to internalize how light levels and shutter speed and aperture size and framing and zoom and depth of field and all of that would interact to produce an actual, physical photograph. More, they also needed to internalize how another person would then see that photograph, to know how, once that photograph was set, the elements of it would draw the eye to one place or another.

They needed to think through the entire photograph, from how they saw the scene, to how the camera would see the scene to how that final picture would give to the audience exactly the sense the photographer had before depressing the button.

Once again, there’s an element of architecture there. When you’re building something, you need to understand how the stresses and supports and elements of your final work are going to interact. Like when kids who are good with Legos are about to build: What pieces do I have? What colors? How can those pieces connect in such a way to become the castle I have in my head? If you just start chucking Legos onto the base - like I did - you’d end up ripping up half of the thing to get it working, and even then, you might not have the time and energy to get through it.

A lot of people talk about how programming is an art, but not enough people talk about how art is a science. The art is the detail, it’s the delicate hows that make up your work. The art of a photograph is the specific way your eye follows the curve of a railing and the shadow it casts towards the face of your subject, and more specifically, how that image is crafted to make you feel. The science of it is internalizing how light exposes on silver nitrate, and how the settings on your lens will leave one part in focus but another pleasantly blurred. You can shoot from the hip with art, and a lot of the time you probably should. But the science? Spending some time working that out may be for the best.

Or perhaps I just feel unproductive in those early days and need to justify it. If so, consider this bit of writing a resounding success.

The problem with trying to convince someone that your security model is dangerous is that, unless you work in something obvious like banking, any scenario you try to throw out as an example leaves you sounding like Cassandra. Worse, as people question why this extra level of security might be needed, you might feel compelled to start throwing out half-baked worst case scenarios. If there’s not some obvious, immediate use to breaking into your system, people’s immediate reaction is to say “So they get a password they shouldn’t. Then what?”

It doesn’t matter if someone can think of a scenario. That you didn’t consider a malicious application of your system or network is no deterrent to those who will. One mistake people make with security is to assume the limit of their own imagination relates in any way to their exposure to actual threat. This is especially perilous when your own faulty assumptions put people paying you for your expertise at risk.

This is not cause to go overboard, but simply to be sensible. Opting for a clearly flawed security model because you don’t think someone has any reason to break it is folly. In most cases anonymous FTP is no danger if the right fences are put around it, but that doesn’t stop many hosting providers from refusing to offer it. They don’t do this because someone gaining access through anonymous FTP is likely, but because the worst case scenario is an unacceptable risk to them. What is the worst case scenario? Something worse than the worst thing you considered.

Requiring insane, impossible to remember passwords is not what I’m talking about. How about something simple like sending a user name and password through clear-text e-mail, but not allowing your users to change either? Or assuming your third party providers have a security policy that’s as tight as your own, and leaving yourself vulnerable if you’re wrong? Or not having a thorough and up to date audit of what any given permission actually opens up across your systems, figuring that users will only open things they’re supposed to?

If people sending you a check are relying on you to be stable and secure, don’t allow arrogance to convince you that the things you haven’t thought of are unimportant. Don’t allow yourself to believe that you are not important or big enough for someone to bother breaking down the door. You’ll always make mistakes and you’ll always miss something. Do yourself, and your users, the favor of at least checking both the doors and the windows before you go to sleep. One way or another, your security prowess is irrelevant in the face of human stupidity and malice. Crackers aren’t relying on your imagination when deciding what to do with your system. There’s always a bigger fish.

If there’s a failure common to many programming sites, it’s the lack of useful examples. This goes both for those high level overview examples you see at the beginning of a chapter and for the actual code samples provided a few pages later. This is a problem for me, since I need context in order to really learn something. Neither seeing a block of code with no explanation of what it’s supposed to be used for in a real system nor reading a superficial example of functionality so simple it does effectively nothing stick with me. I see these examples falling into one of two categories.

The first attempts to turn every programming lesson, no matter how complicated, into a “Hello, World!” example. Need to read from an XML file? Great! Here’s how to load a file with one node, choose the one node that’s already there and read from it! Fun! What you won’t learn is how to use actual XML files where there are lots of elements with a crazy mix of child nodes, inner text and attributes. Want to find out how to read specific information from an XML file based on some kind of criteria? Sorry, no, because all we’re going to give you for an example is:

<Library>
  <Books>
    <Book>
      <Title>The Client</Title>
      <Author>John Grishom</Author>
    </Book>
  </Books>
</Library>

When most XML files look more like this:

<Library Name="Moon Public Library" ZipCode="15108">
  <Books Status="Available">
    <Book Author="John Grisham" DateReceived="3/18/2008">The Client</Book>
    <Book Author="Dan Simmons" DateReceived="3/17/2008">Angels and Demons</Book>
  </Books>
  <Books Status="Checked Out">
    <Book Author="Guy Gabriel Kay" DateCheckedOut="3/10/2008">The Summer Tree</Book>
    <Book Author="Michael Crichton" DateCheckedOut="3/12/2008">Jruassic Park</Book>
  </Books>
</Library>

Only they look worse are even less logical.

The second category try to help you understand the theory behind something by providing a fatuous real world analogy. You know, like, how the best way to describe object oriented programming is to compare a class to a blueprint and an object to the car you make with the blueprint, or to say that you can make a car class, and that a Honda inherits the attributes of a car but adds its own things, like comfy seats and an iPod connector, but you can also have a Pinto inherit from a car as well, but add completely different features, such as ExplodesOnImpact. Which would all be great if I, or anyone reading an entry level programming book, was planning on programming a computer to build cars of every make and model.

Might I suggest that if you require a description of object oriented programming that eschews any reference to things you might actually do on a computer this might be too early to study the topic? I’m not saying you need to have three years of experience here. Just that you might want to stick to programming concepts that you can understand in terms of things you might do with a programming language. Let’s try my own example:

You’re writing Pac-Man, but you want to make it Object Oriented because everything must be designed using this paradigm to be correct. Now, you want 4 ghosts, but you want them to all behave slightly differently. You want Blinky to directly attack Pac-Man, and you want Clyde to always try and cut him off. You could code each ghost separately, but there would be a lot of repeated code. They all basically navigate the maze in the same way, and none of them should be able to eat power-pellets, but they should all kill Pac-Man. So you could make a Ghost class that has the generic behaviors, like movement and speed and all that jazz. Then you can make, say, a Blinky class that inherits the Ghost class, but adds an Attack method that figures out the shortest distance between it and Pac-Man. Instant inheritance!

What most examples lack is good context. What’s that Library example supposed to apply to? Are most people looking for examples on XML because they are in a position to create idealistically clean XML, or are they trying to figure out how to parse the monstrous crap pile that their server at work is dumping on them? You may have shown me what the basic structure of XML is with the example, but not any idea of how I’m supposed to use it. Your example is so much simpler than anything I’ll actually encounter that I can’t apply your example to the real world. And the car analogy? Please, bury it somewhere in the middle of the woods. No one reading it is going to get one of those exclamation points appearing over their head from the sudden shock of understanding you’ve delivered to them.

We program in order to accomplish some task. If you want to teach something, put your example in the context of an actual task so that when I go back to my actual job I can actually frakking apply it.