I’m convinced that there must be two “Bullitt” movies with Steve McQueen. Because all the reviews seem to talk about one of the best action movies ever, the best car chase ever, a great story. They use words like “thriller”, “epic”, and “gritty”, but none of these things apply to the film I saw.
The director made sure that whenever the audience came within view of a potentially tense moment to quickly salve their nerves with at least ten minutes of sleep inducing banter, bored toothpick chewing, newspaper and frozen diner purchasing, car washing, clicky machine watching, plane embarkment and disembarkment, and, of course, coffee house music. Nothing is resolved in the end. And the plot is essentially: witness gets shot, cops slowly work their way from one clue to the next, as they learn more about why the man was killed. Eventually more people get shot, and no-one cares. I’m not kidding. No-one cares. The guy who was impatient to get the witness’s testimony starts reading his newspaper, Steve goes home and washes his hands in the bathroom sink, and the credits roll. The end.
I’m convinced that it would be possible to induce a heart attack in the director simply by going back in time and showing him a modern action flick like The Bourne Identity. And the infamous 100 Mph car chase through San Francisco? It was quite possibly the most boring car chase I’ve ever seen. It’s entirely possible that this was a great action flick by the standards of it’s day, but it’s not by today’s.
On the up side, they did a great job with the transfer to HD so you can watch the boredom in all its glory.
What if I were to write my personal?
What if it were true?What if it spelled out in black and white the things I want in you?What if it held nothing back:my faults, my hopes, my geek…
There are things I want you’ll never be. There are things you want I’ll never have. But maybe… just maybe…that’s the way it’s meant to be.
Perfect little imperfections, that together make up me. Perfect little imperfections, that define who we could be.
Thoughts, feelings, wishes, dreams… Secrets.
Imperfections. Misconceptions.
I’d love to write my personaland show it here to you, but I know it won’t be seen be only you and me.
It’s too dangerous to be openso we put on little shows,that make a pretty face tobring you to your toes.
Single white geeky chick seeks….what? Love Family. The kiss of a beautiful woman?Yeah, that’s it.
Joy: closeness, comfort, laughter, surprises, tenderness, patience, support, desire, ambition, strength, confidence…
Further adjectives, adverbs, nouns and more available upon receipt of same.
P.S. I am so not leaving Boston.
hI’ve been thinking a lot more about Distributed Bug Tracking. I’ve even gone so far as to write up a spec for a new system of handling distributed tickets that could be implemented in any Distributed Version Control system, but I haven’t gone so far as to actually implement it (although it wouldn’t be hard) because of one simple problem: existing systems.
Distributed Version Control is nice because you can sneak it in the back door. It doesn’t matter if your company / coworkers are using a centralized version control system you can always branch from it with your distributed system of choice and then merge back in to their centralized system when you’re done. It doesn’t really matter that people can’t see what’s going on in your personal branches because they’re your personal branches. But tickets aren’t like that. Tickets are all about visibility. The whole point of a ticket system is to give visibility to issues, be they bugs or feature requests. So, while you could easily write a centralized ticket system that was designed to work well with distributed ticket system (my spec makes sure to keep that in mind), I’ve yet to come up with a way to make a distributed ticket system work well with any existing centralized system. The existing centralized systems simple don’t take into account which branch a bug exists in, and they’re all so wildly different under the covers that even if they did you’d still have to write a driver for each one.
The great thing about sneaking Distributed Version Control in through the back door is that when the process and the tools finally manage to get enough recognition by large companies to actually come up for contemplation the ground troops of engineers can stand up and say “Yeah, we know, we’ve been doing it for years, and yes it actually works with our codebase(s).” But I’m just not seeing a good way to do that with distributed ticket tracking.
Two questions have arisen for me, and I’d really appreciate your thoughts on them. Both are predicated upon the assumption that someone’s written a viable distributed ticket system that works with your favorite distributed version control system:1) In order for distributed ticket tracking to catch on do we need to be able to work with existing centralized ticket system that don’t have a clue about branches, like Bugzilla in order to get people to start using distributed ticket systems, or would convincing the few projects that largely eschew centralization be enough?2) If we do need / want to get traction in existing projects that use centralized ticket trackers what functionality is required to create an infrastructure that can work with whatever ticket system a project happens to have chosen and how can we minimize the amount of work required to build drivers for them?
The greatest problem distributed ticket systems will have is visibility. The second greatest problem is data complexity. For any ticket system to succeed people need a place where they can go to see all the tickets that affect a project no matter what branches they do or do not exist in. I believe this problem is entirely solvable but once we have done so we will be faced the the problem of complexity. A distributed ticket tracking system prevents people from continuing to pretend that the state of bugs (and other tickets) is some global binary, where it’s either present or it isn’t. Distributed ticket systems expose Scrodingers Bug to the light of day. We exist in a world where bugs are both live and dead and you don’t know which until you observe the branch it’s in and the wave-form collapses. Any system that allows visibility into the tickets of each branch is going to have to expose those various states and doing so without confusing non-geeks is going to be a tricky UI problem.
I am currently of the belief that until people can use a distributed ticket tracking system in their day to day work any implementation, no matter how good, is largely academic. Furthermore it will continue to be so until the developers of the world have begun to truly understand and embrace the benefits of distributed version control, and judging by the many smart geeks I talk with who still have no real knowledge of them we’ve got a long ways to go on that front.
Piers Cawley just posted about Martin Fowler’s attempt to write a book about DSL’s actually, “internal DSLs”. Piers calls these “Pidgins” and I think it’s a pretty good term for them.
These are the sorts of languages where you don’t write a lexer or parser but instead build a family of objects, methods, functions or whatever other bits and pieces your host language provides in order to create a part of your program that, while it is directly interpreted by the host language, feels like it’s written in some new dialect. – Piers Cawley
Unfortunately ever since Ruby on Rails came out everybody (except Piers) seems to have forgotten what a real DSL is and it’s been driving me batty. Rails is not a DSL it’s a Pidgin. And it seems as if every post about writing DSLs since RoR has actually been a post about writing Pidgins. Which sucked because I, and I assume others, was actually interested in writing DSLs but the only references I could find essentially said “you need to write a lexer and a parser, maybe generate an AST. Go use YACC or Bison”. Which didn’t help me one bit because while I knew what a lexer and a parser were I certainly didn’t want to reinvent the wheel about how to generate them and even now I’m still a little unclear on what an AST is under the covers. I know what they let you do but not how they’re stored or accessed. Also, using YACC always seemed like it would involve journeys into unix obscurity and uber-geekdom. It may actually be trivial to use, I have no idea.
And then, thanks to a friend, I was introduced to ANTLR. OMFGWTFBBQ. ANTLR is the bees knees. It’s got a very nice IDE (ANTLRWorks) in which you write out your grammar using an EBNF-like notation. It will show you the Syntax Diagram of the rule you’re currently working on, and has an interpreter and debugger. Then, for most simple DSLs, you just hook a little code to be executed or returned at various parts of your grammar, click “Generate Code”, and you’re done. I’m not kidding. It’s that freaking simple. ANTLR builds you a lexer and a parser from your grammar, inserts the native method calls you specified and outputs classes for you to stick in the app that’s going to be reading in the DSL. Now by default ANTLR’s focused on Java, but according to the docs you can also generate Python, C#, C++, and more. AND, if you’re writing a language that’s going to do some pretty heavy duty work (like Python for example) then you can also have ANTLR generate an AST for its parser to use which will speed up processing dramatically. I haven’t explored this part of ANTLR yet so I can’t comment on it.
If you’re interested in writing your own DSL (a real DSL not a fucking Pidgin) I highly recommend that you grab the ANTLR book (it’s very well done) and start playing with ANTLR. If you’re not going to be leveraging your DSL from Java you may need to grab the latest version of ANTLR from SVN and you’ll definitely have to read some more of the docs on the site about making it output code in your language of choice.
I was able to get my head around ANTLR, write a grammar for my small language, and then hook in the code to generate a parser that actually did something in roughly one work day. Next week we’re having a brainstorming session at work to see just how far we can take this language and what systems we’d like to retool to take advantage of it.
So please people, stop confusing DSLs with Pidgins and stop writing about Pidgin’s as if they were DSLs. There are so many good reasons to write real DSLs to help in whatever problem domain your applications are addressing, and no good reason to limit yourself to a Pidgin. Real DSLs, like SQL for example, can be leveraged from code in any language and be incredibly useful in their domain.
P.S. You should really go read Piers’ article. It makes some really good points and is covering a different, although related, topic to this one.
Last weekend I broke down and got myself a new phone. I went with the Sidekick Slide. And, I thought some of you might appreciate a review from a geeks perspective.
Requirements for whatever phone I would choose:
I went with the Sidekick because it met all of the above requirements. I considered the iPhone but while there is Jiggy and webapps I’ve seen no real evidence of hackability. I went with the Sidekick Slide because it was the only Sidekick made by Motorola, and they make great phones. I was concerned about the reception because Sidekicks have had a history of shitty phone reception but the Slide and the LX seem to have solved this. I’ve had no complaints whatsoever about reception or sound quality of calls.
Things that rock about the Sidekick Slide:ConfigurabilityYou can set it up exactly the way you want. There’s a setting for just about everything but they’re not done in an overwhelming mass of settings on one screen kind of way. It’s really nice.
Sound ProfilesEach “Sound Profile” has settings for if it should:
Then, to top it off you can have it automatically switch to a Sound Profile at some time every day and back at a later time and / or set it to as specific Sound Profile every weekday weekend (at midnight I assume).
I’ve got a profile for when I’m in bed, one for work, and one for all the other time.
EmailOk maybe it doesn’t “rock” but it’s well done. You can, of course, set separate alert tones for each account. Mail to the t-mobile account is pushed to the phone within a few seconds and all the other accounts seem to automatically poll every five minutes or so. So now, if you send me an e-mail, I have absolutely no excuse not to have seen it.
No special cablesJust a standard mini-usb.
Every app is always on:The virtues of this are kind of subtle. Once an app has been installed and loaded for the first time it’s never unloaded. They do this because phone users expect instant results. Boot times are verboten. But, the cool side-effect is that you can kick off a process in one page (maybe downloading a web page) then switch to another app, and poke around in it, knowing that the process you kicked off is still doing it’s thing in the background.
Great speakerphone:Sometimes I have to go on conference calls from home. The speakerphone sounds excellent to me, and people on the other end claim that it sounds really good to them too with only hearing a slight echo of themselves (which is an issue with most speakerphones).
It feels well made:I’ve got a $250 uber ergonomic keyboard at work. It’s a joy to use but when you pull it out of the box it feels no different than a $20 piece of crap keyboard and that sucks. The Sidekick Slide feels like a really well made device. I’m not a hardware engineer so I couldn’t tell you if it is or isn’t but it really feels like you got something that may actually be worth the $300 you paid for it.
Geeky Goodness: SSH It has an ssh client ($9.99), and if didn’t have one it wouldn’t be hard to port an existing Java ssh client to it.
Twice as much ram as the LX
Anyone can get a dev kit:All you have to do is sign up on their developers site and the license agreement isn’t evil either.
It’s all Java:I realize some of you may see this as a downside but bear with me. It’s ALL Java. It’s a freaking Java OS, and not a trivial little can’t do shit Java OS but a pretty full fledged one. All your MIDP RecordStores are persisted to the server. So, if someone upgrades their phone, all your data goes along for the ride without them doing anything. The fact that it’s all Java means you can’t hack new features into other people’s apps. Overall this is probably good because things would conflict, but it’s frustrating that I can’t improve some of the built in apps but would have to instead make a new similar app.
Extra libs built in so you don’t have to try and fit them into your apps:
Good docs.Dev Kit comes with an emulator.If you’re writing an app that interfaces with the network you can sign up for a free network simulator account.
Random nice touches:
Things that could be better about the Sidekick Slide:
What Sucks about the Sidekick Slide:
Summary:Best damn phone I’ve ever owned (of course the others were all crap so this isn’t saying much), and the only phone I’ve ever been happy with. The only thing that bothers me is the web browsing but I didn’t go into it planning on doing any serious browsing so I’m not very concerned by it. It’s ok in a pinch. While I haven’t sat down to hack out a tool for sharing encrypted messages I am fairly confident that I’ll encounter no major obstacles and I may even get it into the catalog for people like you to buy for your phone. I like the smaller size of the Slide and you can even fit it in a front jeans pocket without discomfort.
If you’re interested in the Sidekick Slide I recommend checking out Phonescoop’s review on YouTube.
[Update] Two annoyances have cropped up. 1) you can’t use if as a bluetooth modem. In fact the only real thing you can use it for is a voice device. 2) I’m really disliking the placement of ths power and headphone jacks. It’s very difficult / awkward to type with them plugged in (especially the power). It would be fine if they were along the top edge.
On any given day I may, or may not, have hermit crabs. I can’t really be sure.
Shortly after acquiring them I took a paper towel roll, wrapped it in a coconut fiber mat, tied it on with an old shoelace; viola! Instant-faux-log with good grippyness for pointy crabby legs, I thought.
It was simultaneously the best and worst thing I could have done. They love it. One crab crawled in each end. They sit there facing each other in the dark, day in, day out. It is possible that, right now, I only have ex-hermit crabs. It’s hard to say. I can see the shell one of them (Jack) carries on his back, but あいた is in the end of the tube pointing away from me. She fell out a couple weeks ago… seemed quite lively at the time. If I sleep on the couch in the living room, and I’m really lucky, I’ll hear one moving in the tube for a few seconds. Sometimes I’ll reach into the tube and pull Jack out, to make sure he isn’t an ex-hermit crab, but he really doesn’t like to be pulled out so I figure it’s not in my best interest to try and hold him because you really don’t want to try and hold an upset hermit crab. They can pinch unbelievably hard. That’s how あいた got her name. She was scared after coming home from the pet store, pinched me in the middle of the palm. It took at least five minutes of continued pain before she let go, and weeks to fully heal.
It’s like a quantum uncertainty paradox. Every day I look over at their aquarium and wonder if they’re alive. It’s really quite sad. I’m always worried about them and I never get to play with them. I know what you’re thinking. “Why not just take out the tube?” But how could I? They love that tube.
I am the proud keeper of two dogs, two cats, and two potential hermit crabs. I’m not sure if I’m “proud” about the crabs though…. “unsure” might be a better word.
Odiogo will take your blog’s rss feed and run it through a text-to-speech converter so that people can subscribe to it as a podcast. It’ll, obviously, have the same quirks as any other text-to-speech converter and is, probably, limited to English but it’s a pretty nifty idea, even if their name is a total rip-off (Odiogo makes rss into podcasts Odeo manages rss feeds of podcasts). Also, they seem to have done a really good job with the intonation of the computer voice.
Ironically I found out about this from a deaf blog. Creating a podcast via normal means would be tricky for a deaf person (you’d have to edit exclusively by sound wave patterns), and, with no disrespect meant, people born deaf tend to sound a little off when speaking, and I would assume that most of them would lack confidence in their speech. I’m know I would. So, this is a great way for deaf bloggers to offer podcasts. Plus, the idea of listening to a deaf blog is just so wonderfully contradictory.
[Update 2: Ditz is the newest player in town and it looks to be the best current option. Go check it out.]
[Update: josef on reddit and Paul in the comments here point to another distributed bug tracker called DisTract but that only seems to work with Monotone, which seems to be the least known or used distributed version control system. Also, I didn't mean to imply that Bugs Every was unique or the first. It was just one of the only ones I found and anyone who is tackling this problem at the moment is a pioneer.]
Panoramic Feedback* has created an interesting tool called Bugs Everywhere (link below) which combines bug tracking with distributed development. The idea is interesting, no, check that. The idea represents a freaking paradigm shift in how we track bugs and one that is really needed. In a world where developers are constantly creating and merging branches it’s entirely common, to find a bug in one branch, but create a new branch just to fix it. A normal bug tracker can’t support this. As far as they’re concerned the bug is either fixed or it isn’t. But, in the distributed world, which bugs happen to be fixed, or exist, in your current branch is entirely dependent upon how the current branch came to be and what other branches you’ve merged into it.
Let’s look at an example. You create a “new_feature” branch off of the trunk to work on a new feature. In the process of creating the new feature you create a new bug. That bug exists in the new_feature branch but not in the trunk. If you never merge that branch back into the trunk does the bug really exist? What if you’re the only one with a copy of that branch. With a centralized system you’d have to file the bug but you’d be the only one who could reproduce it. If a coworker finds a different bug in the trunk and creates a bug_fix_a branch to fix it does it count if he hasn’t merged it back into the trunk yet? What if you merge bug_fix_a into your new_feature branch. Now the fix from bug_fix_a exists in two branches but neither of them are the trunk. If you merge new_feature into the trunk now the trunk has the fix, but unless you were paying close attention and didn’t forget that your new_feature also included the patch from bug_fix_a you might not know you should close out the ticket that was fixed in the bug_fix_a branch (that was never directly merged into the trunk).
A centralized bug tracker is just not capable of accurately managing a bugs status when developers start using lots of branches, even if they’re doing so in a centralized version control system like Subversion, CVS, or Perforce. They can’t even handle it well when you’ve only got a handful of branches like “trunk”, “qa”, and “production”. If you find a bug in “production”, you’d first fix it in “trunk”, but then what’s the real status here. Is it fixed or not? Even if you’ve had 20 people verify your fix it’s still broken for your end users because they’re running code from the “production” branch.
Bugs Everywhere solves this problem. The idea is that the tracking info gets versioned right along with each branch. New bugs are tracked within the repo, which means that you don’t have to keep track of which branches had which bugs and which ones had the fixes too. It allows you to take full advantage of the greatest feature of distributed version control systems (cheap branching and merging) without having to keep track of the bugs. When you merge the branches the lists of present and fixed bugs goes along for the ride. But, there are some problems:
Where we need to improve:
No Windows support
Bugs Everywhere does it’s magic by calling out to the chosen Source Control Manager via the command line, which means it’ll pretty much never work on Windows. I think that there are two solutions that won’t hit this barrier. One is to intimately tie the bug tracker to the version control system so that it will work on all the same platforms. The other solution, and I think this is the better one, is to simply make the bug tracker into a local server that waits for commands via a standard API from whatever wants to talk to it.
Limited Bug Visibility Sometimes you really do want to see *all* the outstanding bugs. Bugs Everywhere has a TurboGears based webapp which appears to be capable of listing / managing the bugs in multiple branches but, you’d have to tell it which branches to watch and it would most likely have to have direct access to them, which means each developer would probably have their own instance of the webapp, and then one that ran on a central server against your main branches. The latter is only a half-way solution because if a developer discovers a bug in a branch they made from one of the main branches they’d only have a record of it in their local branch until they merged back into the main one again. But everyone should be aware of the fact that the bug exists in that main repo.
If, however, we have a local bug server, then we can configure it with the url of a central reporting server where bugs will all filter up to when they’re created or modified (or when the computer regains net access). Or, you could have it act as a client on a peer-to-peer network, and the peers can share bugs for reporting purposes. Anyone could ping all the current clients for a list of their bugs. The former is probably the better solution since it’s much easier to write and debug and all the peers wouldn’t have to keep track of bugs on other boxes in case the other boxes go away for a while. In both solutions, when a bug is fixed any of the other local servers that is tracking that bug could be notified that the bug is fixed and they could, in turn, notify the user of who has the fix and, if possible, where to get it.
In Summary
Bugs Everywhere is a great start, but it’s got some conceptual issues that I believe the proponents of distributed version control need to address in a new, replacement, application. I am, however, very glad that it was created. It represents a workable solution to a problem that no-one else has addressed and people have been blind to, or ignoring, for years now.
Bugs Everywhere can be found here, but, before you go there, please note that the page is horribly out of date. It says Bugs Everywhere only supports Arch and Bazaar, but it actually supports Mercurial (hg) too and be sure not to download the .tgz version that’s release 123 (which probably doesn’t support Mercurial) whereas (at the time of this writing (Jan 2 2008) ) the repo is up to 211 (last update on July 30 2007). Don’t believe the command line help from the repo about supported apps either. It also hasn’t been updated. Oh, and it says that it’s easily extendable. That’s actually true, but you won’t find any docs on how to do it and there are no comments or internal documentation in the code. If you’re interested check out the rcs.py and bugdir.py files. Which revision control system is being used is determined when you call set-root or if you call ‘be set rcs_name ‘ the latter is handled by set.py
Personally, if I didn’t think Bugs Everywhere needed to be replaced by a new generation of distributed bug trackers, I’d suggest rewriting the whole thing from scratch. There are lots of files which probably should be classes but are instead just collections of methods, there are no unit tests, and other files have multiple classes shoved in them which makes it a lot harder to determine where things happen (and test). The one thing it has going for it is relatively readable code, but that could just be a byproduct of it being written in Python.
* What the hell is “360 degree feedback”? The only thing on Panoramic Feedback’s home page that gives me a hint is a short quote, presumably from a customer, about people giving “…honest and candid feedback to one another.” and a quote that it’s the “…most evolved multi-source feedback system.”
