For its part, while acknowledging that one of its phones was indeed the culprit, LG reportedly claimed that dying due to such an accident was “virtually impossible.” [From Korean man killed by exploding cellphone - Engadget]
For what it is worth, I did some freelance work a few years ago for WebView. One of their clients was inspecting polymer materials used in battery construction. They were very aware of the consequences of shipping pinholed product.
Here’s a weird thing that happened while working with VMWare Server. While trying to get one of my virtual machines bridged to our corporate LAN, I kept getting an error that no dns servers were configured.
The fix was to force the VMnet0 controller choice rather than allow it to bridge to an automatically chosen adapter. By doing that, the virtual machine was able to get an IP on the LAN.
This was for a Windows XP host machine and the configuration is performed by the Virtual Network Editor located on the host at VMWare Server > Manage Virtual Networks.
A new site, walkscore.com, helps calculate how walkable an address is.
The site generates a WalkScore(tm) by measuring distances to walkable locations near the address and presents the results as a google map mashup. Of course, there are limitations such as safety, pedestrian friendly design, freeway intersections, weather, etc.
The site is focused on helping real estate brokers and buyers evaluate the walkability of their property. Real estate websites can generate a widget to embed on their pages.
However, this service combined with satellite imagery is bound to give walk-minded travelers a good idea of what ground transportation they may need (or not) at a destination.
The WalkScore may also have some usefulness as an inverse suburban sprawl score. Low scores are probably not desirable for people who want to walk for exercise or community services.
Here are scores from local downtown areas:
Carrboro - 89
Raleigh Moore Square - 89
Cary Downtown - 82
Apex Downtown - 65
Holly Springs - 38
40. (with egg) Visual Studio, Ruby on Rails, and Old Dudes Who Know Smalltalk
I really love Old Dudes Who Know Smalltalk! I was nurtured, sculpted, and brainwashed by Old Dudes Who Know Smalltalk from my very first day as a professional programmer, and they universally “get it”. Young whipper-snappers out there, take note: if you ever here (sic) some Old Dude say the words “in Smalltalk you could blah blah blah” or “In VisualWorks you could yada yada”, spend as much time with this person as possible. You will learn more from them about software development than the Young Dude who only wears black and thinks that the bash shell is “too bloated”.
Oh… I am so feeling the love. One old dude benefit is in recognizing useful language features. I immediately fell in love with Groovy after seeing it’s Closures implementation. (By coincidence, I’m listening to Jason explain Closures on a WebDevRadio interview. He wants to whip out his Mac and show you, but… it’s radio). Likewise, being interested in tools to better exploit processor concurrency, I’ve been studying Erlang and have to say that I’m really disappointed with the bulky syntax. It just isn’t very readable, IMO. I much prefer the clean syntax of Scala.
Update: Merlyn has similar issues with Erlang readability, though attributes it to style rather than language syntax. I have to admit, the solution gives me hope.
One day there will be statements about the Old Dudes Who Know Ruby. I don’t really expect to be around for that one, but trust me; it will happen.
Henry Butler played last night in the Nelson Music room at Duke University. The solo Jazz piano concert was part of the Following Monk series, celebrating Thelonious Monk’s 90th birthday on October 10th. Monk was born in Rocky Mount, though didn’t stay long. He was known for the sparse voicings in his left hand.
Mr. Butler started the show with a couple of Monk evoking tunes, but in homage to Monk’s short stay in Rocky Mount, Butler soon left Tribute Town and began a heavy handed program more in the villages of McCoy Tyner and Oscar Peterson. In honor of the style, I’ve created a Big Handed, Old School, Jazz Pianists Who Stomp Their Left Feets station on Pandora.
The show was great and warmly received, but 90 minutes was enough for me. Great Jazz doesn’t always require foot tapping to 4/4 time.
Over at InfoQ, Geoffrey Wiseman comments on Why Agile Adoptions Fail. It could have mockingly been titled “Agile Fails When Individuals Aren’t Sufficiently Impressed by the Process”. Ironically, many of the reasons he summarizes from Jean Tabaka’s original list blame the individuals involved.
Exactly why should people care about any grand poobah of process? A friend surprised me the other day by saying he wanted to be a development manager. I asked why. He said that as a programmer there is no shortage of people that want tell him how to do his job. But for managers, no one tells them how to do their job. They are only responsible for results.
There you have it. No one wants to be arbitrarily told how they should work. Offering solutions to their day to day headaches will get you respect, however.
Jared Richardson does a great talk on Gradual Agile from his NFJS rotation which he shared with Agile RTP recently. Stealth Agile would be an appropriate title as well. The case study he presents is a great example of introducing agility in a way that wins friends and influences people. One of the golden nuggets in there:
Your agile toolbox has everything in it needed to solve real business problems.
For a long time in our startup, I was slightly embarrassed by never having a “good” answer to the question, “What agile methodology are you using?” The implication was that if it wasn’t Scrum, XP, or some other labeled process, then it must not be agile, i.e. worth consideration.
The thing is though, we intrinsically knew that the Agile Manifesto was the right attitude to adopt for our team. People solutions were favored over process, primarily. We didn’t try to get Ruby/Rails running on a network processor doing gigabit encryption (although once we considered a JVM) to prove agility. We simply applied agile solutions whenever there was a business issue to be solved. Every practice we adopted as a team; unit testing, continuous integration, retrospectives, etc., was a response to a business problem, scaling issue or point of pain in the daily grind.
There were many times that we interacted with customers and certification bodies interested in our “process”. Most of the time, the questions they had were oriented towards waterfall type work flows and artifacts. We’ve never had any trouble mapping our agility to the “best practices” that were expected by these groups.
Rather than boiling the ocean and rewriting from scratch to have a process described in a book, we refactored. Not adopting agility wholesale, but gradually; recognizing that we had problems that could be fixed with agile solutions.
So, how do you eat a hippo? One bite at a time. You can go agile that way, too.
NoonHat is a pretty cool concept. During a CED event that I attended a while back, one speaker encouraged everyone to have lunch occasionally with someone outside of their inner circle; preferably outside of their industry. That seems to be Brian Dorsey’s motivation for NoonHat as well.
It’s pretty good advice for two reasons. We benefit from the constant exercise of pushing the boundaries of our personal space. Meeting new people and sharing experiences is like many other skills; the more practice you get, the easier it becomes.
Another is that as technologists and entrepreneurs, we should always be on the look out for pain points. Unfortunately, nails are the only problem gleaned from a group of people all holding hammers. So expand your contacts and increase your understanding of other peoples’ daily grind. It’s likely that early NoonHat adopters will be techies, but over time, hopefully the word will get out.
NoonHat encourages you to bring a friend which sounds like a perfect idea if one-on-one discussion with someone you just met makes you squeamish.
Unfortunately, no one was available for my first attempt. I’ll keep at it by choosing every other Thursday as my NoonHat day and try again the first week of September. If your NoonHat shadow falls across Raleigh or Durham, then let’s do lunch.
Is ‘Fred’ a Name with Renewed Cachet?
Michael Levin, of the NFJS tour, ate a box of questions for breakfast. We need a side of answers to go.
My greatest take away from BarCampRDU this year was the Coder to CTO session. It wasn’t the session itself and I’m not particularly interested in being a CTO. It was something that was said.
Know Why You’re Doing This.
Is it for money, prestige, time, leadership, recognition, location, independence? Whatever. There isn’t a wrong answer. Just know why you’re in the game because that’s how you measure success and also how you frame the disasters. It hit me like a ton of bricks.
For those of you who know me well, you know that I left my startup in March for a more traditional enterprise job. After the head smack in Saturday’s session, I realized that I haven’t been completely honest with myself about what and why. Honesty is a quality that is at the center of the best personal relationships I have. So why is it so hard to come to terms with it solo?
I decided to turn the statement inside out and think about things and situations I can’t do without; just to see what I can learn about myself and see if I can get a little closer to knowing the whys.
So really… Is this news to anyone? Because I was working in an embedded environment with a strongly typed language, sometimes I thought that maybe we weren’t keeping up with state of the art. But, we had check in builds, full nightly integration builds with unit test execution and live network verification. We would have automated the regression tests too, except that many of them relied on unprogrammable test gear. Our system test group watched the nightly build results and pulled builds they wanted to test and release.
Now I come up for air and see the state of the builds in some local companies, it just makes me want to pull my hair out. Thanks to those of you who shared your horror stories. I had no idea. But I am glad your frustration has driven you to seek some solutions.
How did I do? At least I can refocus on the things I can’t do without. I need a few more quiet hours to reflect on the why.
I’m no stranger to language refresh. I’ve gone from assember to C, then C++ to Smalltalk to Java back to C++ with STL and Boost and recently back to Java. My current infatuation is Groovy. There’s so much possibility there to reduce the development friction of Java apps. But as Steve Yegge put it recently, you get to a certain point where you really need to be careful about what you take on.
If you have any ideas, thoughts along those lines to help me out or want to share a similar decision you’ve made, I’d sure love to hear about it. Cruise over to my new tangle and drop me a line. Thanks in advance.
No foreheads were actually harmed in the construction of this journal entry.
