18 March 2015

More Insights on the Hobbit Walk

This is sort of in line with my previous post, as I was a little frustrated (with myself) that I’d not had any progress on the Hobbit Walk (there’s another reason, too).

Anyway, on to what I’ve found.

First, it’s a little frustrating to name a race.  Naming is one of the hardest tasks there is… well, besides cache invalidation.  I should be able to dynamically set the name of the race, because I’ve already stored the list of participants.  I kept teetering between dynamic versus static naming.  Ultimately, though, it seems like static (or maybe “arbitrary” would be more apt) naming.

Second, it’s nice to know who created the race.  Right?  That allows explicit listing of the races I’ve created, allowing “creator” permissions (like deleting them).  Maybe I’m waiting on the other person to accept (which I may not have considered yet).  Or I want to see all of my races, including all the ended ones.

Third, sometimes I try to normalize the data too much.  This one’s another tough one.  When I started working on TTORP, I had very non-normalized data: I wanted to get something up and running fast, so I just threw a bunch of arbitrarily-named fields in a database, all of which were just text… I was bit by this laziness later, because I had to pay the technical debt.

I found all kinds of other little things in the process.  Countless little nuances that I could spend all night enumerating, finding even more in the process.

Anyway, the bottom line is that I’ve made progress.  I’ve got more information in my test database, which will help me to visualize things.  At this point, unless I find more problems, I should be able to start spitting out some progress information in the very near future.  Stay tuned!

Category: Code, Health, Hobbit Walk, Software Development | Comments Off on More Insights on the Hobbit Walk
18 March 2015

Programming Isn’t Just Typing

There’s a lot more to programming than just typing.

Somebody once said, probably jokingly, that what I was doing amounted to nothing more than typing.  It might have been one of those things where they say, “I’m joking,” afterward to keep me from being offended.  The first time it was said, it was funny.  The next few times, it lost a bit of humor.  After more than a dozen times, I have a hard time faking a smile.

The point here is that programming follows the 80/20 rule: 80% thinking and/or planning, and about 20% actually programming.  The typing part is actually a really small part… of that 20% programming part, about 80% of it ends up being debugging and testing.

Category: Code, Rant, Software Development | Comments Off on Programming Isn’t Just Typing
2 March 2015

We Have Milestones!

After much waiting: there are now milestones!

Yep.  A bit of a let-down.  I know.  Sorry.

In creating the milestones, I noticed there were some things that were probably missed… setting up an order to the milestones (so I don’t necessarily have to insert them in the proper order), etc.  Nothing mind-blowing here.

I’m working on the code and associated SQL to figure out a contestant’s progress in relation to milestones.  Nothing exceptionaly difficult, just takes a little time to do.

But there are MILESTONES now, people!

Category: Code, Health, Hobbit Walk, PHP, Software Development | Comments Off on We Have Milestones!
19 February 2015

Beware the five o’clock stupids

My brain gets a little “squishy” after working on something for awhile.  Pounding away at the same thing gets a little monotonous.  Over.

And over.

And over.

And over.

And over.

And oevr.

And orev.

And voer.

Adn over.

And oevr.

And OVER.

AND OEVR.

AND OEVER.

ADN VEORE.

AND OEFER.

(see what I did there?)

Wait… what do you mean you can’t find /lib/std++.so?  WTF IS THAT?  Oh… shit…

At 5:00, relative to your timezone.  Stupid strikes.  BEWARE THE FIVE O’CLOCK STUPIDS.

4 February 2015

Project Hobbit Walk: There’s a Database

That’s right, now Project Hobbit Walk actually has a database behind it.  And that database is actually getting data put into it.  Automatically.  Huzaaaa!

I’ve still got a bit of work to do.  But this is an incredibly important foundational piece of the puzzle.  With a single query, I can see how far everyone has traveled.

The only numbers I have to worry about are each user’s grand total, and their progress since the race against me started.  So it’s pretty non-complicated right now.  WOOO!!!

I’ve still got more stuff to do.  Here’s a pretty short list, in no particular order:

  • a URL scheme for showing race data:
    • for anyone (e.g. “/race/{id}/current”)
    • for all races of the currently logged-in user (e.g. “/races/”)
    • for progress on a specific race, up to a given date (e.g. “/race/{id}/20150104)
  • a URL scheme for handling open invitations (anyone can click it, sign up, and enter the race): (e.g. “/race/challenge/open/{id}“)
  • a URL scheme for handling user-specific invitations (only for a selected user, others get an error) (e.g. “/race/challenge/closed/{id}“)
  • some way to graphically show progress generically, without milestones
  • a way to show, graphically, progress with milestones (e.g. progress to Mordor)

Okay, that’s probably enough for now.  I’ll probably dream about this stuff now, since I’m thinking about it so close to bedtime… d’oh!

Category: Health, Hobbit Walk, Software Development | Comments Off on Project Hobbit Walk: There’s a Database
19 December 2014

Project Hobbit Walk: Preliminary Ideas

I’ve got some data from a few other people, so I’ve been thinking about it.  And be sure to read the teaser.

The Basics…

I’m going to setup the system so each user can compete in multiple “races.”  I’ll automatically keep track of each person’s complete history, and I’m thinking each will get put into a separate race that will be just them.  So I’ll be in my own race, showing my own progress from whenever I first got data into the system.

Other Types of Competitions

There will of course be other races.  I might challenge my buddy “John” to a race that will start on January 1st, and simultaneously begin a race today with my other buddy “David” right away today.  So those are examples of one-on-one races, though there could be multiple participants: if another person wanted to jump into an existing race, they could, though they’d be at a disadvantage (but a marathon runner joining late in a race with a couple of geeks might end up having a much larger advantage).

Another race type would be pairs.  In the vein of Lord of the Rings, you know, like Frodo and Samwise.  Each pair would have their daily totals averaged… think of it like Samwise carrying Frodo when he couldn’t walk on his own.

For Now…

Right now I don’t have anything setup to automatically track progress.  I’ve got some spreadsheets that have been shared with me, but that’s pretty much it… so I’m probably going to send out emails manually, stating results.  I’ll refine them as I go.

Into the Future!

That seems like a quote.  Anyway, the initial races will be based on the Walk to Mordor from Nerd Fitness, which has milestones along the way that I can use.  I hope to incorporate an ACTUAL map from LoTR, with something that shows where each team is on the trail.  Because that’s awesome.

Once I’ve got that down, it’s time to open it up to accept ANY map.  I have no idea how that would work… but I would imagine I’ll have a lot more to go off of after I’ve done that with the LoTR map.

Are You Ready to Get Started?

If you’re interested in joining the fun, I’m accepting a limited number of participants right now.  Send me an email (if you’re privy to that info), or just drop a comment below, I’ll get to you as soon as I can. 🙂

Category: Health, Hobbit Walk, Software Development | Comments Off on Project Hobbit Walk: Preliminary Ideas
17 December 2014

Project “Hobbit Walk”: The Teaser

I’m working on a new project that combines fitness, programming, and technology (the last two seem a bit redundant… but whatever).

The project is based upon the “Walk to Mordor” post on NerdFitness.com.  Anybody that’s interested just needs to setup a spreadsheet on Google Docs that I can access, with some basic information:

  1. Date
  2. Steps
  3. Distance (in miles)

There’s a bunch of different ways to get that information logged… manually is an option, but I think that kinds sucks.  Not a big deal, but it’s a pain to remember, especially when you can use something like a Fitbit with IFTTT on a smart phone (or tablet) to automate that stuff.   More on that later.

If you’re interested, send me an email, say something in the comments below, or in some other way express interest to me.  I’ll send you instructions on how to get started.

The application is in ALPHA testing now.  Alpha testing means pre-beta… basically, that means that I’m still building it.  I’m letting a handful of people in right now.

UPDATE: see “Preliminary Ideas

UPDATE: see “Yay Progress

UPDATE: see “There’s a Database

(if you wanna see all updates, in case I missed a link, check out the “Hobbit Walk” category).

Category: Code, Health, Hobbit Walk, Software Development | Comments Off on Project “Hobbit Walk”: The Teaser
9 October 2014

Understanding Dynamic Webpage Updates

There’s a lot of ways to make your webpage update without requiring the user to refresh the page.  The way Facebook updates your news feed while you’re looking at it.  Or Google+, or Twitter, or whatever.

I’m going to talk about just three ways: Polling (with Ajax), Web Sockets, and Comet (or “long polling”).  There’s a ton of different variations of ways to may pages update dynamically.  I’m not going to talk about Flash, or Java, or other icky things (I’m looking at you, Silverlight).

Polling (via Ajax)

Polling the server, using Ajax, was the first way used to make pages interactive.  Your browser would use Javascript to periodically ask the server if anything has happened.  Maybe once every few minutes, or sometimes up to every second (or as quickly as it could, in some cases).

Ajax is a combination of a few technologies, and can be a bit confusing to talk about… so let’s distill it down.  Basically, your browser asks the server, “hey, did (X) change?” to which the server would mostly respond, “no.”  When there’s a change, some part of the displayed page would get that updated bit of information.  Pretty over-simplified, but that’s the gist of it.

The problem is that the server is getting asked a lot of questions.  It’s like reloading the webpage constantly to see if there’s a change: given enough people, that puts a heavy burden on the server.   To fix this, Comet and Web Sockets were created.

Web Sockets

The concept of web sockets is, in its simplest form, that the server will respond when something has changed.  Instead of asking every second for 30 seconds to get a single response (asking 30 times if something has changed), web sockets kinda says, “hey, just let me know when something changes.”  The server only sends back when something actually has changed: in our scenario, that means we’ve eliminated 29 questions.

Unfortunately, Web Sockets is a feature that isn’t 100% supported. Well, it is mostly supported in the newest browsers, but not necessarily completely.  Not in all of them.  And older browsers?  Yeah, they’re screwed.

Comet

So polling is cool, but it’s fairly taxing on the server.  Web Sockets is a cool idea, but isn’t completely supported.  In comes Comet to create that middle ground.

Essentially, comet is just like polling, but with a twist: instead of returning a response immediately, as with polling via Ajax, the server would hold on to the request, and only respond after a certain amount of time or after something changed.  Basically the same as Web Sockets, except… well, different.

The great thing about comet is that pretty much all modern browsers support it.  In fact, even most of the older browsers support it!

Category: Code, Software Development | Comments Off on Understanding Dynamic Webpage Updates
4 March 2014

Why MS Access Application Developers Should Be Ashamed

If you have written what you consider to be an application in Microsoft Access, you should be ashamed of yourself.  MS Access is not a developer-friendly environment.  Not even a little bit.

You might think, “oh, but I’m just making this simple little application, and it’s not going to be used for very long.”  Wrong.  The company you made it for is going to use it until the amount of money they’re spending on maintenance vastly overshadows the amount it would cost to create a real application to replace it.

“No, that’s silly,” you might think, “I told them this thing won’t scale.”

Well, kudos to you for realizing that MS Access is a pile of crap, and for realizing it doesn’t scale.  But the company isn’t going to do anything about it.  Because if it ain’t broke in a way that costs a lot of money, don’t fix it.

“I told them I’ll rewrite it as soon as I have time.”

You’re never going to have time.  Once this thing gets put to use, you’re going to spend all your time fixing it.

Eventually, you’ll leave the company, probably because the pain of maintaining that application was too stressful.  That’s where I come in.  And I hate you for doing this to me.

That’s right, I’m the guy that gets hired to maintain the pile of shit you left behind.  And guess what?  The company has no money to spend on creating a real application, because they’ve spent all of it maintaining that thing.

Without further ado, here’s a few of the many, many, many reasons why MS Access isn’t developer-friendly:

  1.  Source code can’t be maintained.  Go ahead, tell me there is–and prove to me that you’ve used them successfully.
  2. Debugging is a joke.  If the application gets closed, all those breakpoints are gone, and trying to step through it is like scalping yourself and then replacing your own hair with individual strands of silk from a black widow spider.
  3. Changing the code will RESET THE PROJECT.  So those breakpoints you spent an hour setting are ALL GONE.
  4. Only one developer can work on it at a time (see #1).  If more attempt to, the result will be that somebody’s change will get overwritten.  But neither will know who did it, what’s missing, or why.
  5. The source code is obscure, difficult to access, and can be password-protected.  Because that’s a good idea.
  6. You have to know the application’s “secrets” to develop on it (like holding <shift> while opening the file)
  7. Pretty much any programming language that still uses “GoTo” should not be used anymore.

If you’re thinking about writing an application in MS Access: DON’T.

Category: Code, Rant, Software Development | Comments Off on Why MS Access Application Developers Should Be Ashamed
19 February 2014

Why Coding and Smalltalk Don’t Work

So, when I’m working on code, and somebody starts trying to talk to me, I sometimes get funny looks from them when I can’t respond right away.  Or because they have to wait a significant amount of time before I let them talk.  Or because I get frustrated right away when they just start talking anyway.

I’m not intentionally being an asshole.  But I do get frustrated by it.  Switching to and from programming/coding isn’t like switching to/from a book or an article or whatever.  It’s way way more involved.

There’s a fair amount of time required to get (back to) programming.  Like one of those choose-your-adventure novels, only… more.

If you chose “I’ll go with the stranger” on page 2, but didn’t take the candy in chapter 12, and you’ve got a machete (from pages 12, 13, 405, 7004, or 7005), go to page 803..  If you chose “I’ll go with the stranger” on page 2, didn’t take the candy in chapter 12, and you’ve got a machete from pages Honey? 85, 99, or 9008, go to page 405.  If you chose “I’ll go with the stranger” on so I was at the store today page 2, didn’t take the candy in chapter 12, and you’ve got a machete from a page that is NOT 12, 13, 85, 99, 405, 7004, 7005, nor 9008, go to page 777.  If you chose “I’ll go with and I saw Jerry the stranger” on page 2, didn’t take the candy in chapter 12, and you don’t have a machete at all…

So now the stranger’s name is Jerry.  And I got the machete from a store… wait, there’s no chapter called “store” in here… SHIT.

Category: Code, Rant, Software Development | Comments Off on Why Coding and Smalltalk Don’t Work