In mountain view, CA. Finished vacation in ID, OR, and WA.
Avatar

Jeff Pitman

Vcard Download vCard   what is this?
Rss_icon

Recent Activity

Filter by:
All
  • Brilliant Noteput Table Teaches Music by Touch and Sight
    Shared by Jeff Pitman
    Wouldn't be surprised to see an iPad version.
    The designers employed the visual programming language vvvv and fiducial markers to build the interface. On his site, Friedemann Heuer explains, ...
    6 months on
    Jeff Pitman's shared items in Google Reader
  • Mashup Of Scrum, Lean And Kanban: Scrow

    You learn a lot when you are trying to combine methods and approaches. Yes, we talked about it before: mashups.

    That is why I like this presentation by Lasse Koskela performed at Oredev a little over a month ago.

    “… teams are dropping Scrum to go Kanban. We see good ideas in all of these methods and are adopting them with an evolutionary approach. This session presents Scrow, a mashup of those very ideas.”

    Click here to watch the presentation.

    Other people who liked this article liked these too

    Subscribe with iTunes to "The Project Shrink" video podcast.

    Mashup Of Scrum, Lean And Kanban: Scrow

    Mashup Of Scrum, Lean And Kanban: Scrow
    8 months on
    Jeff Pitman's shared items in Google Reader
  • No Comet, Hacking with WebSocket and Akka Over the weekend I upgraded my Chrome to the developer channel and played around a bit with Web Sockets. It's really really exciting and for sure will make us think of Web applications in a different way. Web Sockets have been described as the "TCP for the Web" and will standardize bidirectional communication technology for Web applications.

    The way we think today of push technology is mostly through Comet bsed implementations that use "long polling". The browser sends a request to the server and then waits for an event to happen and then sends a response. The client, on getting the response consumes it, closes the socket and does a new long polling connection to the server. The communication is not symmetric and connections can drop off and on between the client and the server. Also, the fact that Comet implementations are not portable across Web containers make it an additional headache to portability of applications.

    Atmosphere offers a portable framework to implementing Ajax/Comet based applications for the masses. But still it does not make the underlying technology painless.

    Web Sockets will make applications much more symmetric - instead of having long polling it's all symmetric push/pull. Once you get a Web Socket connection, you can exchange data between the browser and the server through send() method and an onmessage event handler.

    I used this snippet to hack up a bidirectional communication channel with an Akka actor based service stack that I was already using in an application. I needed to hack up a very very experimental Web Socket server, which did not take much of an effort. The actors could do message exchange with the Web Socket and communicate further downstream to a CouchDB database. I already had all the goodness of transaction processing using Akka STM. But now I could get rid of much of the client code that looked like magic and replace it with something that's more symmetric from the application point of view. It just feels like a natural extension to socket based programming on the client. Also the fact that Javascript is ideally suited for an event driven programming model makes the client code much cleaner with the Web Socket API.

    Talking about event based programming, we all saw the awesomeness that Ryan Dahl demonstrated a few weeks back with evented I/O in Node.js. Now people have already started developing experimental implementations of the Web Socket protocol for Node.js. And I noticed just now that Jetty also has a WebSocket server.
    8 months on
    Jeff Pitman's shared items in Google Reader
  • Dragon Dictation comes to the iPhone. Wow. (Mel Martin/TUAW)

    Mel Martin / TUAW:
    Dragon Dictation comes to the iPhone.  Wow.  —  Put this into the 'I didn't think they could ever get this to work on an iPhone' category.  —  I'm talking about Dragon Dictation [iTunes link] from Nuance, the developers of the very popular Dragon Naturally Speaking for the PC.
    9 months on
    Jeff Pitman's shared items in Google Reader
  • The Benefits of Feature Teams

    When I first began to consult for a certain California-based game studio, its teams were organized around the specific elements and objects that would exist in the video game it was developing. There was a separate team for each character. There were weapons teams, a vehicle team, and so on. This led to problems, such as weapons too weak to kill the monsters, colors too dark to show secret passages, and obstacles that frustrated even the most patient player.

    On more traditional, corporate projects, we see equivalent problems when teams organize around the layers of an application, including

    • Reduced communication across the layers
    • A feeling that design by contract is sufficient
    • Ending sprints without a potentially shippable product increment

    If structuring teams around the layers of an architecture is the wrong approach, what’s better? Rather than organizing around components, each team on a project can ideally be responsible for end-to-end delivery of working (tested) features. There are many advantages to organizing multiteam projects into feature teams:

    • Feature teams are better able to evaluate the impact of design decisions. At the end of a sprint, a feature team will have built end-to-end functionality, traversing all levels of the technology stack of the application. This maximizes members’ learning about the product design decisions they made (Do users like the functionality as developed?) and about technical design decisions (How well did this implementation approach work for us?)
    • Feature teams reduce waste created by hand-offs. Handing work from one group or individual to another is wasteful. In the case of a component team, there is the risk that too much or too little functionality will have been developed, that the wrong functionality has been developed, that some of the functionality is no longer needed, and so on.
    • It ensures that the right people are talking. Because a feature team includes all skills needed to go from idea to running, tested feature, it ensures that the individuals with those skills communicate at least daily.
    • Component teams create risk to the schedule. The work of a component team is valuable only after it has been integrated into the product by a feature team. The effort to integrate the component team’s work must be estimated by the feature team, whether it will occur in the same sprint during which it is developed (as is best) or in a later sprint. Estimating this type of effort is difficult because it requires the feature team to estimate the integration work without knowing the quality of the component.
    • It keeps the focus on delivering features. It can be tempting for a team to fall back into its pre-Scrum habits. Organizing teams around the delivery of features, rather than around architectural elements or technologies, serves as a constant reminder of Scrum’s focus on delivering features in each sprint.

    Of course, there will be occasions when creating a component team is still appropriate, for example when a new capability will be used by multiple teams or when the risk of multiple solutions being developed for the same problem is high. Overall, however, the vast majority of teams on a large project should be feature teams.

    Additional advice on feature and component teams can be found in Chapter 10, “Team Structure,” of Succeeding with Agile.
    9 months on
    Jeff Pitman's shared items in Google Reader
  • Defining Useful Coding Practices? markmcb writes "A NASA engineer recently wrote about his disappointment that despite having well-documented coding practices, 'clever' solutions still made the code he has to maintain hard to follow. This got me thinking about the overhead spent at my own company regarding our code. We too have best practices that are documented, but most seem to focus on the basics, e.g., comments, modularity, etc. While those things are good, they don't directly ensure that quality, maintainable code is written. As the author points out, an elegant one-liner coupled with a comment from a few revisions ago makes for a good headache. I'm curious what experience others have had with this, and if you've seen manageable practices that ultimately offer a lot of value to the next programmer down the line who will have to maintain the code."

    Read more of this story at Slashdot.
    9 months on
    Jeff Pitman's shared items in Google Reader
  • Reducing One Amino Acid Could Increase Lifespan John Bryson writes "Eating less of one amino acid might lengthen your life. There have been lots of previous studies showing that many species live long on highly restricted calories, but a lot of this benefit may be possible by only restricting one amino acid. Amino acids that have shown this have been tryptophan and methionine. A recent study, published online December 2 in Nature, a highly respected journal, may help explain some of the health benefits of restricted-calorie diets."

    Read more of this story at Slashdot.
    9 months on
    Jeff Pitman's shared items in Google Reader
  • Two Weeks, 5 IPhones Sold in Chinese Online Store (Owen Fletcher/PC World)

    Owen Fletcher / PC World:
    Two Weeks, 5 IPhones Sold in Chinese Online Store  —  China Unicom has sold just five iPhones through a big online retail site in the two weeks since it opened the virtual store, the latest sign that the handset is suffering in China from its high price and lack of Wi-Fi.
    9 months on
    Jeff Pitman's shared items in Google Reader
  • Google Tries Not To Be a Black Hole of Brilliance theodp writes "Google says it's declined to pursue awesome job prospects to avoid an over-concentration of brilliance at the search giant. Speaking at the Supernova conference, Google VP Bradley Horowitz said the company intentionally leaves some brainpower outside its walls: 'I recently had a discussion with an engineer at Google and I pointed out a handful of people that I thought were fruitful in the industry and I proposed that we should hire these people,' said Horowitz. 'But [the engineer] stopped me and said: "These people are actually important to have outside of Google. They're very Google people that have the right philosophies around these things, and it's important that we not hire these guys. It's better for the ecosystem to have an honest industry, as opposed to aggregating all this talent at Google."'"

    Read more of this story at Slashdot.
    9 months on
    Jeff Pitman's shared items in Google Reader
  • FCC Preparing Transition To VoIP Telephone Network mantis2009 writes "The US Federal Communications Commission (FCC) published a request for public comment (PDF) on an upcoming transition from the decades-old circuit-based Public Switched Telephone Network to a new system run entirely with Voice over Internet Protocol (VoIP) technology. This is perhaps the most serious indication to date that the legacy telephone system will, in the near future, reach the end of its life. This public commenting phase represents a very early stage in what will undoubtedly be a very complex transition that makes this year's bumpy switch from analog to digital television look relatively easy."

    Read more of this story at Slashdot.
    9 months on
    Jeff Pitman's shared items in Google Reader
  • Harvard Says Computers Don't Save Hospitals Money Lucas123 writes "Researchers at Harvard Medical School pored over survey data from more than 4,000 'wired' hospitals and determined that computerization of those facilities not only didn't save them a dime, but the technology didn't improve administrative efficiency either. The study also showed most of the IT systems were aimed at improving efficiency for hospital management — not doctors, nurses, and medical technicians. 'For 45 years or so, people have been claiming computers are going to save vast amounts of money and that the payoff was just around the corner. So the first thing we need to do is stop claiming things there's no evidence for. It's based on vaporware and [hasn't been] shown to exist or shown to be true,' said Dr. David Himmelstein, the study's lead author."

    Read more of this story at Slashdot.
    9 months on
    Jeff Pitman's shared items in Google Reader
Next page