API's that Suck

June 3, 2012

I am a computer programmer. I read for a living.

Filed under: Uncategorized — Grauenwolf @ 12:44 am

My job is reading. Sometimes I write, but mostly it’s about reading. Every day I start by reading my email to see if anything blew up over the night. In the past I would spend each breakfast poring over ops reports, but these days it is rare that I need to do any production support work.

Hopping on the train, I’ll spend the next hour reading the 300+ blogs and news feeds that I actively track. Most articles are just skimmed and forgotten, but the ones that are potentially news worthy are flagged, reread, and ultimately forwarded to our lead tracker.

Showing up at work, I put InfoQ aside and turn to the needs of our clients. This usually starts by reading requirements documents, bug tracker entries, and other such task-based documentation.

I am primarily a backend developer. This means I’m constantly being tasked to deal with interoperability between our new software, existing client software, and countless third-party systems. Often this means reading through 100+ page specifications that may be accurate, but are most likely complete works of fiction. That will take me to lunch.

During my lunch break I read bookmarking sites, mostly Reddit. I do this in part to blow off steam by arguing about pointless topics, but also to find out if all those blog entries I’ve been reading are legit or bullshit.

After lunch I start reading code. You see, I’m not just any old backend developer. I’m the backend developer that’s routinely assigned to ongoing projects. While others are building new software, I find myself tasked with figuring out why the client’s 20 year-old PowerBasic application is having performance problems. Or maybe I’m tracking down race conditions in a Silverlight application that is so big it looks like it is 20 years old. I read a lot of code.

Check-in a bug fix and then read some more. I mentioned third-party systems, right. Well generally speaking “third-party” means “you don’t get a development environment”. A lot of my code never runs outside of production, even when that code deals with million dollar trades. Like a human computer, I trace through each line of code executing it in my mind. I don’t even bother with mock testing anymore; mocks just trick me into thinking that I know more about the black-box on the other side of the connection than I really do.

Signing off for the day, I’m back on the train home. (Oh fun, more half-baked blogs to read.)

Eat dinner; then pick up a book to read. Often it’s a new technology and I’ve got to interview the author. Right now I’ve got a half-complete interview for Lightswitch on my desk and a pair of books about Go on the nightstand.

Other times the book is a work in progress for APress. In publishing a technical editor is a proof reader for grammar and syntax. Once they are done they hand the draft over to me, the technical reviewer, the proof reader for code and content. I have to read and reread every line of code in a 500+ page book on C#. There are no bug patches for a dead-tree book, I’ve got to get this right or my author will look like an idiot. Fortunately I usually get soft copies so I can at least paste some of it into a compiler. Back in the 90’s I would often get printed drafts to markup in pencil and overnight back to the publisher.

After the books I start on InfoQ’s educational articles. InfoQ doesn’t have the resources of a major book publisher, so I’ve got to play the role of both technical reviewer and technical editor. And until we get some more leads (yes, we’re hiring), I’ve got to handle JavaScript, PHP, Objective C, Go, Android-style Java, and any esoteric language that our readers happen to find interesting this month. Spotting bugs in languages that you don’t really know, without access to the right compilers, takes quite a bit of practice. And a lot of reading.

Time to sleep? No. Next I’ve got to read the news reports by my reporters in training. And I’ve got to read all of their sources to make sure they are accurately reporting what’s going on.

I am a computer programmer. I read for a living.

Post script: And now that I’m actually done working for the day I find myself with a longsword in one hand and a 16th century German fencing manual in the other.

April 24, 2011

Why doesn’t anyone know how to implement the factorial function in C++ with proper error handling?

Filed under: Uncategorized — Grauenwolf @ 8:48 pm

Not too long ago I asked this question on Stackoverflow,

How do you implement the factorial function in C++? And by this I mean properly implement it using whatever argument checking and error handling logic is appropriate for a general purpose math library in C++.

Of the five answers I got only four actually showed any code. Of those not a single one was production quality, they all all just cute ways to answer homework problems. In fact someone tagged my question as “homework” and others closed it as a duplicate. Not a single one correctly handled n=-1, nor did any of the examples in the questions they linked to.

Seeing that the moron squad didn’t even bother reading the question and only glanced at the headline I asked again. This time making sure to include “with proper error handling” in the title. I got two more answers, this time with no code what so ever and again no discussion on proper error handling in C++.

Why are applications and operating systems still so unreliable after all these years? Possibly because the C++ community that they are based still thinks “undefined behavior” is the correct response whenever someone passes in invalid arguments.

March 12, 2011

Design Driven Development

Filed under: Uncategorized — Grauenwolf @ 5:56 pm

Step 1: Requirements

Read the requirements. All of them. Breath them in and get a feel for what the customer really wants. And how that changed since you last read them all.

Once you feel the Tao of the project, grab a block of related requirements. How big of a block? Whatever feels right. We call this a “feature”.

Step 2: Design the Features

Start by writing the use cases, the step by step explanation of how the feature is going to actually work from the user’s perspective. Then start adding any database schema, class diagrams, test cases, flowcharts, and anything else you need to understand the feature. The key word here is “you”. No one else needs to see the design documents. Well, unless you happen to be using them a prop to show why they are high.

Step 3: Bitch about the Requirements

Invariably the requirements are going to have holes, areas that are unclear, underspecified, or written by someone who is clearly high. The only purpose of the design process is to find those holes and get them fixed. Once you fill your written design with highlighted question marks, crack open a beer and relax. It is going to take product management ages to figure out what the hell they really wanted you to build.

Step 4: Review the Design

Get a good night’s sleep. Or party till you drop. It doesn’t really matter, just so long as you let the design age a bit.

Now take a look at it. Does it still make sense? Or was it clearly written by a crack head and need to be redone?

Step 5: Hacking

Now you know exactly what you want its time to grab some energy drinks and start writing the code. If you are using automated testing now is the time to slap them together. Heck, you can even go full TDD at this point. I prefer ADD, but that’s just me. Just don’t forget to update the design documents with whatever edge cases or significant redesigns you happen across.

Step 6: Testing

Remember all those use cases and test cases you wrote back in step 2. Of course not. Go look at them again, I’ll wait…

Now really test your code. Automated what-you-ma-call-its don’t count at this point. Actually go through the requirements and design documents and verify everything matches what you expected.

Step 7: Documentation

Find your tests cases can give them to the QA department. Then throw everything else away. You know damn well you aren’t going to keep it updated, so don’t even bother pretending you will do otherwise.

February 27, 2011

CIL Parameter Passing: By-value, By-ref, and Typed Reference

Filed under: Uncategorized — Grauenwolf @ 1:33 am

The common language runtime supports three kinds of parameter passing.

By-value

By-value parameters work as one would expect. Primitive types are simply copied onto the stack, as are value types, object references, managed pointers, and unmanaged pointers.

CIL Type: typename

By-ref

By-ref parameters of course references to other values. Any of the types that can be passed by value can also be passed by reference. However there certain restrictions. In order to get a reference to a value, that value must have a home. A home can be any of the following:

  • An incoming argument
  • local variable of a method
  • An instance field of an object or value type
  • A static field of a class, interface, or module
  • An array element

At first glance the list appears to be comprehensive, but something is missing. Intermediate values, those which are on the stack but are neither a local nor a argument, do not have a home and thus cannot be referenced.

CIL Type: typename&

Typed Reference

A typed reference parameter is a reference to a home matched with the argument’s type information. Normally it isn’t necessary to explicitly pass the argument’s type information as one of the following is usually true:

  • The argument is a value type that matches the parameter type
  • The argument is a reference type and thus the type information is encapsulated.
  • The argument is a boxed value type, again with the type information encapsulated.

It is only when the argument is an unboxed value type that doesn’t necessarily match the parameter type that a Typed Reference is needed. This will never occur in a early-bound language such as the original version of C#, but it can in late-bound language such as VB with option strict turned off.

does and not

one that combines a by-ref parameter with extra type information. The reason this is necessary is that it is possible for an argument to otherwise lose it’s type. This occurs when…

  1. The parameter is a value-type. Value-types do not internally store their type unless boxed.
  2. The parameter is passed without boxing.
  3. The argument’s type doesn’t necessarily match

CIL Type: typedref
CLR Type:
System.TypedReference

February 13, 2011

Meditations on Testing

Filed under: Uncategorized — Grauenwolf @ 1:20 am

There is never enough time, so first test that which you are uncertain about.

If it is easy to test, it is easy to write. If it is easy to write, it didn’t need to be tested.

Test the way the program will be used, not the way it should be used.

A wise student tests his code. A wise master tests everyone else’s.

A test is not a debugger. Nor is a debugger a test. Learn them both.

The student saw asks his master, “Why do our tests take so long to run?”
The master replies, “The services are slow.”
The student then asks, “Why don’t you mock the services so we can run the tests faster?”
The master deletes all of the test code and says, “The tests are now fast.”

All combinations of user input should be tested. Configuration files are user input.

To not test what the compiler can prove.

Play with the clock.

If a child can break it in an hour, and adult can in 5 minutes.

January 29, 2011

Foundry – Goal: Build a compiler that will print “Hello World”

Filed under: Uncategorized — Grauenwolf @ 8:52 pm

The goal is to create a CLR compiler for Foundry, my research project for this year.

Source File

Program Test1
    References
    mscorlib
    End References
End Program
Imports 
    System

End Imports
Function Main 
    Let message = “Hello World”
    Console.WriteLine(message)
End Function

Tasks

  1. File level parser. This needs to understand import statements and function blocks, but not the contents of functions.
  2. Level 1 symbol table. Requires reflecting over core assemblies
  3. Parsing let-style variable statements. This will require an abstract syntax tree with nodes that can later be annotated with type information.
  4. Level 3 symbol table for storing locals. (Level 2 is for class-level symbols, which donof’t apply to free functions. Levels 4+ are for nested structures)
  5. Parsing simple function calls.
  6. Emitting a free function as IL code.

Abstract Syntax for File-Level Parser

<Import> <Identifier>

<Function> <Identifier “Main”>

<Function-Body>

<End Function>

The file-level parser doesn’t concern itself with the contents of functions. This allows us some degree of error recovery, as one bad function will not prevent us from parsing the remainder of the file.

Proposed object model (using XML notation because I don’t feel like drawing diagrams tonight)

<File>

    <Imports><Import Namespace=”xxx”></Imports>

    <Free-functions>

        <Function Name=”Main” />

    </Free-functions>

</File>

Deadline: My self-imposed deadline is March 12, which allows for weekly milestones.

August 12, 2010

All, and I mean literally all, version control systems are an embarrassment to our industry.

Filed under: Uncategorized — Grauenwolf @ 10:39 am

To start with, all systems that physically tie branches to directory layouts are just plain stupid. Code should be organized by the structure of the project. When you have to contort it to the needs of the VCS then something wrong.

The stream-based systems like AccuRev and ClearCase are closer to what VCS should be. But last time I checked AccuRev didn’t even have any support for build management. What’s the point of having the ability to easily move features from one stream to another if you can’t then build the damn thing? As for ClearCase, it is so buggy and temperamental you need a team just to babysit it.

The file system should be playing an active role too. Without any action by the developer, the file system and VCS should be tracking every revision to every file. And those revisions should remain available to me until I “checkpoint” the file and commit them to my private branch.

Check-ins should be based on features, not just change-sets. When I commit a set of files it should prompt me to strongly associate it with an issue or project number. Not just a soft-link like TFS does, I want a solid association where I can move the whole feature from one branch/stream to another branch/stream.

When pulling down code, I should be able to say “Get this branch/stream plus features X, Y, and Z”. I should then be able to say “Remove feature Y and recompile”. For this to work we also need to be able to indicate what the real dependencies are between features. Simply guessing that A requires B but not C because A and B have overlapping files is a good start, but we need the option to mark C as required as well.

Blind text comparisons aren’t enough, VCS systems need to deeply understand project and source files. When I add or remove a feature X from my local workspace, it should know how to update my project file accordingly. And it shouldn’t get confused just because project X and project Y both added the same file, but by chance put them in a different order in the project file.

Unit tests should never run on my machine. There should be a separate machine watching the changes on my machine and rerunning the applicable unit tests every time I change a file. When I notice something go red, the real-time versioning I mentioned in the third paragraph can be used to show me exactly what I did to break the test.

June 7, 2010

Web Apps: Because you don’t have time to piss off users one at a time.

Filed under: Uncategorized — Grauenwolf @ 10:49 pm

image

March 29, 2010

Security, Superstitions, and Stackoverflow

Filed under: Uncategorized — Grauenwolf @ 2:37 pm

Today I needed to translate a Stackoverflow post. Most translators including Google and Bing use frames, which Stackoverflow doesn’t like. So I write to them to inform them of the problem.

This was their response:

Hello,

That’s present to present malicious framing, see:

http://www.codinghorror.com/blog/2009/06/we-done-been-framed.html

http://stackoverflow.com/questions/958997/frame-buster-buster-buster-code-needed

 

The first link has this conclusion,

Yes, Digg frames ethically, so your frame-busting of the DiggBar will appear to work. But if the framing site is evil, good luck. When faced with a determined, skilled adversary that wants to frame your contnet, all bets are off. I don’t think it’s possible to escape. So consider this a wakeup call: you should build clickjacking countermeasures as if your website could be framed at any time.

The second link includes step-by-step instructions to counter “frame-busting” code.

So basically their stance is that frame-busting code is worthless, but they are going to use it anyways. Am I missing something or have they completely lost their mind?

December 17, 2009

Conjecture: Oracle is Building a MySQL Backend that Targets Oracle Database

Filed under: Uncategorized — Grauenwolf @ 2:03 am

Ok, so here are my facts and assumptions

  • MySQL is the most popular choice for small websites that need a database backend.
  • Unless you have a ton of development resources devoted just to customizing MySQL, eventually those sites are going to outgrow the MySQL.
  • All the major database companies (Microsoft, Oracle, and IBM) would love to offer an upgrade path to their produce.
  • MySQL’s Pluggable Storage Engine, with or without some rework, can support these database servers.
  • MySQL’s Pluggable Storage Engine can only be used if you are willing to offer GPL code.
  • Microsoft, Oracle, and IBM are not going to release key components under the GPL.

New facts from Oracle’s Press Release

1. Continued Availability of Storage Engine APIs. Oracle shall maintain and periodically enhance MySQL’s Pluggable Storage Engine Architecture to allow users the flexibility to choose from a portfolio of native and third party supplied storage engines.

MySQL’s Pluggable Storage Engine Architecture shall mean MySQL’s current practice of using, publicly-available, documented application programming interfaces to allow storage engine vendors to "plug" into the MySQL database server. Documentation shall be consistent with the documentation currently provided by Sun.

2. Non-assertion. As copyright holder, Oracle will change Sun’s current policy and shall not assert or threaten to assert against anyone that a third party vendor’s implementations of storage engines must be released under the GPL because they have implemented the application programming interfaces available as part of MySQL’s Pluggable Storage Engine Architecture.

A commercial license will not be required by Oracle from third party storage engine vendors in order to implement the application programming interfaces available as part of MySQL’s Pluggable Storage Engine Architecture.

Oracle shall reproduce this commitment in contractual commitments to storage vendors who at present have a commercial license with Sun.

That pretty much knocks off all the major roadblocks between the big three database and MySQL. With Oracle taking ownership of MySQL, they technically don’t need to lift the GPL restrictions on plug-ins. But by doing do they legitimize their plans to offer an Oracle backend and fend off any possible anti-trust disputes.

Older Posts »

Create a free website or blog at WordPress.com.