Sunday, October 6, 2013

CSS

So a lot of what I do at work ends up being targetted for the web. Despite me thinking web programming is a blight on humanity. Realistically, I've managed to abstract away the web-ness of most of it behind some decent libraries, so I can pretend it's not the web. But occasionally I have to actually write some HTML and CSS.  And let me tell you, my opinion is that CSS is AWFUL.

Here's why:

1. It's unintuitive and inconsistent.

I'm not talking about the general concept, or the block model. Sure, you have to learn those. But they aren't hard. I'm talking about stupid stuff like vertical-align, which means two completely different things depending on the context. In a table cell, it means one thing. In an inline element, it means something completely different. 

Or absolute positioning. One would think positioning of "absolute" instead of "relative" means positioning the element absolutely. Instead, it's just a different type of relative, technically: "In the absolute positioning model, a box is explicitly offset with respect to its containing block" ...or in other words, it's relative to some parent above it. (W3Schools states it as "An absolute position element is positioned relative to the first parent element that has a position other than static.")

It also kills me that specifying a width of 100% for an element gets really messy if there's a margin or padding. Because the padding is included in the 100%, but the margin isn't. Or maybe it's the other way around? I'm sure CSS junkies remember. Normal humans don't. All I know is that percentage widths break down when margins and padding are around. 

Now I know people that are used to CSS will defend many of these things, but having used a large number of other layout toolkits in other programming environments, none of them make me scream and pull my hair out like CSS does.

2. No grid layout.

Why, oh why, isn't there a grid layout? Maybe because the table html element already exists, which is a perfectly good grid layout. Oh wait, all presentation-related code is supposed to be moved to css, and tables should only be tables of data.  Unfortunately, there's no real replacement for tables for grid-based layouts. So for a layout that should naturally be a grid (ie a form of labels and text fields), you end up with a mess of absolutely sized nested divs or other ridiculous workarounds.

People have come up with all sorts of hacks and frameworks to get around this issue. Great, we can hack our way past it. It's still terrible design.

3. It replaces one set of hacks and problems for another set.

When people first got all excited about separating content from presentation, it seemed like a good idea. Unfortunately, HTML and CSS are terrible at letting you actually do so for any vaguely interesting design.  So either your presentation bleeds into the content (37 divs for a piece of content, just so the header, header corners, edges, etc, can all fit together to make it look right), or you end up with all sorts of hacks and nastiness in CSS and Javascript frameworks to try to trick your browser into doing something it wasn't designed to do.


So what can we do about it? Not much, unfortunately. The web is what it is. All sorts of CSS and javascript framework are written to try to make it easier. I guess you can use one of those. Or maybe just avoid web programming in general, that seems more pleasant.

Saturday, October 5, 2013

Debugging on Pebble

So I'm currently working on a fancy alarm clock app for Pebble for a friend of mine.  It allows up to 10 independent alarms, with different schedules (and different types of schedules, ie "every day at 9am" or "every 2 hours"), and the ability to sync (using HttPebble) with a web app so that the alarms can be managed from a web page, and to synchronize their status (since there's no persistence on the pebble itself).

Let me just say, this has been harder than I expected.

The first draft, to get the alarm functionality working, was actually pretty straightforward. I wrote the code, pushed it to the watch, and, with a couple obvious tweaks, it just worked. When does that ever happen?

The next step was to use the HttPebble protocol to sync stuff (yes,  my friend uses iOS) This has been the painful part.  Let me count the ways:

1. I have to do a fair bit of string manipulation in passing data back and forth. Anyone who's done much with C knows how primitive the string manipulation functions are. To top it all off, Pebble's limited environment doesn't even include all the standard C string functions, so I had to rewrite a simple implementation of a few of them.)

2. There's just no real testing/debugging tools for Pebble. During the kickstarter project they said there'd be an emulator, but it's pretty clear that they promised more than they could provide. When it doesn't work, it's really hard to tell why.

3. I've had some weird network issues at home that have made it even harder to test, because I'm never sure if it's my code or if my phone just can't talk to my test server.

Ugh.

I think I'm finally getting close. The watch properly (via the phone) sends the status of any repeating alarms to the server, which saves them and can echo them back to the pebble. The only thing I need to fix is the pebble parsing and understanding the alarm definitions that the server sends, which it's currently failing to do.

Level loading and scrolling engine

Well, after a bit of work here, a bit there, between baby feedings and lack of sleep, I've managed to get the first bits of my level-loa...