I never really liked cats...

...but this has pushed me over the edge. The "LOLCATS" madness will pass.
Making things better.

...but this has pushed me over the edge. The "LOLCATS" madness will pass.
Posted by
Matt McKnight
at
2:56 PM
0
comments
Labels: cats, internet silliness
A little bomb I defused today in an ASP application I am replacing...weirdness explanation at the end.
nextTuesday = ""
showTuesday = ""
gotTuesday = 0
todayDate = weekdayname(weekday(now()))
'response.Write(todayDate)
if todayDate = "Monday" then
holdNextTuesday = date
nextTuesday = formatdatetime(date,1)
' response.Write("got it")
else
j = 0
'do until gotTuesday = 1
do while showTuesday = ""
j = j + 1
if j > 10 then
response.write("ERROR: Infinate loop
" & j)
response.write(weekdayname(weekday(nextTuesday)))
response.end()
response.flush()
end if
nextTuesday = DateAdd("D",j,Date)
'response.Write(weekdayname(weekday(nextTuesday)))
if weekdayname(weekday(nextTuesday)) = "Monday" then
gotTuesday = 1
holdNextTuesday = nextTuesday
nextTuesday = formatdatetime(nextTuesday,1)
showTuesday = nextTuesday
end if
'response.write(nextTuesday)
loop
'nextTuesday = ""
end if
thisMeetingDate = holdNextTuesday
'response.write thisMeetingDate
previousMeetingDate = DateAdd("D",-7,thisMeetingDate)
----
The meeting date was moved from Tuesday to Monday and they didn't change the variable names. I have no explanation whatever for the "infinate loop" check. That one just kills me.
Posted by
Matt McKnight
at
12:33 AM
1 comments
Labels: bad code
"Nearly impossible to crash runtime or VM" -From Nutter and Enebo's MountainWest RubyConf presentation.
I managed to do it on a daily basis for years, the simple recipe is to add WebLogic to the project.
This is not to take anything away from their achievement with 1.0. It's a Java application running nearly as fast as a c application. I am very curious to see if it's as compatible with horizontal scaling...
Posted by
Matt McKnight
at
12:24 AM
0
comments

I've been listening to the audiobook of 10 Faces of Innovation by Tom Kelley of IDEO. He has a great insight into something I sorta knew, but had never thought about why it was so.
The basic idea is that showing just one prototype to a customer is bad. This tends to force them into a binary/reactive decision, one that is often determined more by their relationship to the creator of the prototype than to the item itself. Given multiple items to evaluate, the attention turns more to the items, and more feedback can be gathered, since it won't be perceived as direct criticism.
The telling analogy Kelley provides is that of a husband that is told by his wife that she has purchased a new dress. She then tries it and asks how it looks. Of course, it is difficult for the husband to say anything negative, because the question is really about how she looks wearing that dress. However, given multiple options to consider, the husband is actually more free to give honest feedback.
Now, it can be expensive to buy multiple dresses, or build multiple prototypes. The answer then is to use lo-fi prototypes: whether it be pictures in a magazine or crude drawings. Still, the more prototypes that are created, the less pressure there is to get it right the first time, which is a crushing force against innovation.
Having heard his brother speak at a conference in 2006, I love what IDEO are doing. If didn't need to make quite so much money, and had any confidence in my abilities, I would like to work there...just to live at that creative level every day would make me so happy.
Posted by
Matt McKnight
at
11:33 PM
0
comments
Labels: ideas, innovation, prototyping

A must for Neal Stephenson fans, the RSS telegraph gives you all of your feedy goodness in Morse code.
Saw the steampunk turntables on BoingBoing- might have to trade in the 1200s.
Steampunk...
Posted by
Matt McKnight
at
11:18 PM
0
comments
Labels: steampunk
I've had this in draft for a while, can't figure out what the point was, but I don't want to think about it anymore. I've seen so many people chafing about the enterprise IT shop at one of my clients...unfortunately only I can do is add another forlorn whine to the choir.
My friend sixty4bit recently blogged about some trust and power issues at a client we have both worked for. Their behavior is bureaucratic in the extreme, they run all projects through a slow and cantankerous review board for all of their technology selections. In the end, the review board exists because the organization does not trust software developers and does not want to empower them to make decisions. The end result is that they slow everyone down and drastically reduce the effectiveness of the organization. The overall atmosphere created is one of fear of anything new, where people stop asking to try new things, because it isn't worth the time to get them approved. In a lot of cases, you have to get approval just to try something.
Laughably, this client is attempting to move to agile development processes, which are certainly focused on empowering the people who are doing the work to make decisions (although that is more of a Lean idea), while continuing on the opposite track in terms of empowering individual projects to meet their customers' needs.
In reality, particular technical decisions about technology selection can be contentious, especially in regards to projects across the enterprise choosing incompatible technology stacks. There is also a need to coordinate purchases across projects to gain negotiation leverage. Even more important, although completely overlooked by these bozos is that the license terms for all software need to be read by actual lawyers. However, it's clear that the real issue here is one of trust and power, tied up with the fun of getting to decide how to spend other people's money.
I am working on a devious plan to: a) get them to trust me, b) keep them feeling powerful, and c) allow for innovation and progress. Reading "Influence: Science and Practice" by Robert Cialdini tonight. Maybe that will help with a and b.
Posted by
Matt McKnight
at
12:03 AM
3
comments
Labels: enterprise it departments that are completely failing

Pretty big round for uLocate. Famous for providing support for Flagr, the mobile version of MapQuest etc.
I tried to download the new Where (how much did that domain name cost?) app to my phone, but it's not supported as of yet...
Their mobile technology is sorta cool- going for the whole write once run anywhere thing for mobile apps with an xml style application definition. A location specific version of something like mFoundry. Of course, when they don't support your phone, it's a little harder to buy into that concept.
Anyway, XML as a programming language? Just because it worked sorta okay for HTML doesn't mean there aren't better ways to do it- especially when you are talking applications.
Posted by
Matt McKnight
at
11:05 PM
0
comments
Labels: gis, mobile applications, xml
For work purposes I am currently carrying two phones- a Blackberry and a Palm 650. I like both of these OSes, although the Palm OS does crash quite a bit. I've also been testing a couple of mobile GIS applications running on Windows Mobile 5. We're trying to figure out where to go next with it- RIM, Symbian, Linux (iPhone), etc.
While I like RIM and Palm OS, with a edge to RIM, Windows Mobile is completely unappealing to me. The main plus from a development standpoint is that it is relatively standard across devices. However, this is easily eclipsed by the usability, the memory consumption, and the way in which closing most programs doesn't close them- it just hides them. The stability varies pretty widely across devices, but it's about on the level of Palm OS.
I am still waiting for the mobile OS that implements virtual memory paging (with an SD card as the pagefile holder). It might be slower, but the RAM is so easily consumed in simple apps, it would enable a variety of applications that just don't work now. I know, you just have to wait a couple of years and it will all change, but right now it's a very tough decision if you want to figure out which mobile OS to develop on.
Now, some might say- why not just do mobile friendly web applications versus applications? For a lot of applications, you need more interactivity than the limited browsers on the phone provide. For others, the constant lag is the impediment. Overall, it's an area of potential, but limited to only the simplest applications today.
However, the mobile device is where some of the virtual machine technologies can really come to bear. In particular, Java Mobile Edition is pretty widely available, even if the apps look as out of place as they often do in Desktop OS land. So, you can do a Java app and get a reasonable percentage of phones to work, although they all seem to implement slightly different profiles.
Now we have the Apollo, Silverlight, JavaFX model of what are in reality enhanced web browsers that build UIs out of things other than HTML. JavaFX mobile is one picture of how things could go in that direction, where the environment could provide all of the basic phone functions, in addition to providing a decent programming environment for content delivery. Of course, I am not sure how much of that is really one thing, or if it's a set of technologies that Sun is lumping under one banner.
Anyway- let's say I have an opportunity to port one of these mobile GIS apps to a platform or OS- which way should I go?
Posted by
Matt McKnight
at
4:52 PM
0
comments
Labels: gis, mobile applications
Scott Simpson: I love saving things to del.icio.us w/ a "toread" tag. Offloading work to the future, incredibly productive, version of myself. [link] Kind of a cool idea for using del.icio.us, especially if you use the firefox plugin. Just highlight a bit of text and then tag it. So easy. I haven't gotten as much out of the more advanced del.icio.us bookmarks plugin, but that might be because my current bookmarks are a pile of junk.
The main garbagey bit about del.icio.us is that there is no good way to manage tags with the default apps. Idea! I am going to hunt around to look for someone that has done that or start digging into the API a little bit.
I guess one of the main competitors to this stuff is Google Notebook, but I really don't enjoy using that for some reason I don't yet understand. Those little links in the search results pages are tempting thought.
Posted by
Matt McKnight
at
10:28 AM
0
comments
Labels: ideas
Thinking again. One of the things Steve Poland is going after is the concept of webothlike:
Basically the idea of WeBothLike.com is to connect like-minded people — people that have the same interests. You’ll go to the website and answer questions, as many as you want. The more you answer, the more profile data we have on you — and the more we can contrast you with others in our system, and match you up with them
I think rather than asking questions it would be better to try a recommendation style algorithm on your del.icio.us links, or bookmarks, etc. so that you could get a match score for how similar you are to other people. Basically you could submit all of your links and get a quick score for who else is tagging the same things as you. You could take a similar approach with OPML comparisons to find who is reading the same things as you. On the one hand, the output of this would be suggestions about what to read- and really, who doesn't have too much to read already? On the other hand, a cooler output suggested by WeBothLike would be to find people to scheme with.
Anyway, I have a feeling someone has already done this somewhere, but it's not part of the main del.icio.us application, and it probably should be.
Posted by
Matt McKnight
at
3:38 PM
0
comments
Labels: ideas