My name is James Bigler. I am a software developer. This blog is mostly a collection of links related to software programming and technology.
Search This Blog
Monday, December 21, 2009
Saturday, December 19, 2009
Wednesday, December 16, 2009
Tuesday, December 15, 2009
Entity Framework POCO (EF4): A Simple Mapping
The latest EF4 CTP released on November 12th includes updated support for POCO’s (Plain Ol’ CLR Objects). Although we could use POCO’s in the previous CTP, we still had to create an EDMX artifact to model our entities, thus leading to a bit of duplication.
In this post I want to take a look a simple mapping scenario, and how that looks using the new ‘Code Only’ API. By using the code only API I can have complete control over my entities, giving me the most flexibility in my mapping strategies, better testability and extensibility, and ultimately greater maintainability. No generated code. No XML files. Sweet
Sunday, December 13, 2009
A quick out (west) and back - Mtbr.com Forums
A quick out (west) and back Passion
Thursday, December 10, 2009
Wednesday, December 9, 2009
Tuesday, December 8, 2009
Wednesday, December 2, 2009
Localizing NHibernate: Contextual Parameters
Tuesday, December 1, 2009
Download Visual NHibernate
Download Visual NHibernate - visual designer and mapping tool
Monday, November 30, 2009
Chapman's Coding Corridor: NHibernate Non-Mapped Joins
Friday, November 20, 2009
Tuesday, November 17, 2009
Thursday, November 12, 2009
NHibernate 3.0 QueryOver
One of the personal reasons that I had for co-founding Guild 3 was for me to re-discover my passion for software. I was suffering from something similar to what Davy Brion (quite bravely) outlined in Avoiding (Or Recovering From) Burnout. For me the age old adage of “a change is as good as a rest” has proven to be an extremely successful strategy.
Sunday, November 8, 2009
Thursday, November 5, 2009
Wednesday, November 4, 2009
Back on the rails
Tabaka writes:
You’ll know that you have seriously moved to a truly collaborative style of decision making when:
- You value the opinions of the group more than your own.
- You provide process guidance through positive encouragement instead of controlling dictatorship.
- You provide your opinion only as an expert contributor and only with the permission of the group(more on this later).
- You don’t use your opinion to sway the outcome of the meeting.
- You enlist others to dog your neutrality and ensure it is engaged throughout the meeting.
I do value the opinions of my team and believe that they can make a better decision together than I can make by myself. I have worked hard on being neutral and giving my team the power to make decisions, but I really need to work on being positive and supportive.
I have been avoiding providing my opinion. I don't know how to give my opinion without making it sound like the final decision. The book says it will talk more about this later so I am hoping there is some advice in there that can help me. The idea of getting someone to dog my neutrality sounds interesting.
Monday, November 2, 2009
Sunday, November 1, 2009
Thursday, October 29, 2009
#dev10 Visual Studio2010 b2 IntelliTrace (historical debugging) shows all the SQL Statements #NHibernate sends. No need for NHProf!
#dev10 Visual Studio2010 b2 IntelliTrace (historical debugging) shows all the SQL Statements #NHibernate sends. No need for NHProf!
Wombling - Fall 2009 - Mtbr.com Forums
Wombling - Fall 2009 Passion
Dave's Hairy Monster. - Mtbr.com Forums
Dave's Hairy Monster. 29er Bikes
Wednesday, October 28, 2009
Tuesday, October 27, 2009
Sunday, October 25, 2009
First Impressions: TekPub
OK Folks. I don’t do endorsements. I especially dislike commercial / corporate training. The trainers aren’t really experts. They didn’t create this stuff. They don’t even use this stuff. They just *teach* this stuff – day after day, city after city. I can learn 95% of the material with my laptop and 15 minutes with the slide deck.
What’s the alternative?
Blogs? They’re fine for keeping up with trends and knowing what the cool kids are doing, but if you’re trying to learn something from scratch, you’ve got to dig for the good stuff. The worst part about web 2.0 is that any idiot can start a blog about stuff he doesn’t really understand – even me.
Books? While I could recommend a few, the honest truth is that I’ve had a dozen queued up on my bookshelf for nearly a year. Even if you do take the time to read, the information is out of date before the book even hits your shopping cart. On top of that, you have no guarantee that the author is really an expert.
Here’s something different.
Rob Connery @robconery and James Avery @averyj started TekPub.com. That’s @tekpub on Twitter. It’s a library of professional screencast series by Rob, James, and other subject experts with names you’ll recognize. They’re not little 30 minute channel 9 interviews with obscure Microsoft PMs. First, the message is not corporate in any way, shape, or form. Second, the quality is amazing. The audio is clear. The text is crisp and easily readable. The images are both humorous and relevant to the topi
Saturday, October 24, 2009
A student-designed velomobile
As you know, I like to share student designs from time to time. Joseph Campbell is a recent design graduate whose senior thesis project “dealt with bicycles and how they do not fit into Americas current grid”. As someone who has cycled for transportation for many years, I don’t completely agree with that statement, but I do see his point. There is much more that can be done both with infrastructure and with various types of pedal powered vehicle designs that can open human powered transportation options up to a larger segment of the population. I won’t discuss the inadequacies of our current transportation system in this post. Instead, I will share Joseph’s thoughts about the velomobile that he designed in his own words:
Friday, October 23, 2009
Thursday, October 22, 2009
Reading gets personal with Popular items and Personalized ranking
(Cross-posted with the Official Google Blog)
Today, we're launching two changes to Google Reader to help you discover more interesting content faster. Just as the launch of Personalized Search improved search results based on your search history, these changes use your Reader Trends to improve your reading experience.
- Explore section - We're always trying to help you discover new stuff in Reader, and today we're introducing "Popular items" and "Recommended sources", two ways to find interesting content from all over the Internet. We use algorithms to find top-rising images, videos and pages from anywhere (not just your subscriptions), collect them in the new Popular items section and order them by what we think you'll like best. Now you don't have to be embarrassed about missing that hilarious video everyone is talking about — it should show up in your "Popular items" feed automatically. And to make it easier to find interesting feeds, we're moving recommendations into the new Explore section and giving it a new name — "Recommended sources." Like always, it uses your Reader Trends and Web History (if you're opted into Web History) to generate a list of feeds we think you might like.
Monday, October 19, 2009
Wednesday, October 14, 2009
Monday, October 12, 2009
Characteristics of a Collaborative Team
a collaborative team holds the following set of characteristics:
- They are self-organizing versus role- or title-based in organization.
- Teams are empowered to make decisions versus being dictated to by an outside authority.
- Members truly believe that, as a team, they can solve any problem.
- Members are committed to success as a team versus success at any cost.
- Trust versus fear or anger motivates the team.
- They aggressively engage in participatory decision making versus bending to authoritarian decision making or succumbing to bullying for decisions.
- Decisions are consensus-driven versus leader-driven.
- Teams maintain an environment of constructive disagreement versus falling into damaging conflict or no conflict at all.
The other day my boss was asking me what the vision for my team would be. I think this is a very good start.
I just finished the "Why" section of Jean's book, and I am moving into the "How" section. I am very excited to try out her suggestions with my team.
Sunday, October 11, 2009
DISC model of team roles
- D: you can describe this person as demanding, forceful, egocentric, strong willed, driving, determined, ambitious, aggressive, and pioneering.
- I: you can describe this person as convincing, magnetic, political, enthusiastic, persuasive, warm, demonstrative, trusting, and optimistic.
- S: you can describe this person as calm, relaxed, patient, possessive, predictable, deliberate, stable, consistent, and tend to be unemotional and poker faced.
- C: you can describe this person as careful, cautious, exacting, neat, systematic, diplomatic, accurate, and tactful.
Teams tend to be imbalanced if a majority of the people on the team have the same personality role. This imbalance happens frequently because people tend to gravitate towards like minded and like acting individuals.
Teams with too many "D" types tend to be very results-oriented, but they don't produce very high-quality work or very detail-oriented solutions. Decisions are made based on speed and who has the strongest or most dominating personality in the group. Team meetings are marked with frequent power struggles, grandstanding, and little collaborative output. These teams are constantly running as fast as they can, straight into brick walls and then on to the next great idea or initiative.
Teams with too many "I" types tend to enjoy debating and brainstorming but have trouble really making any productive progress. These teams are weighed down with endless design meetings and can't focus enough to fully understand the details of the software they are building.
Teams with too many "S" types tend to hyper aware of how everyone is feeling, but they take too long to come to decisions. In addition previous decisions can be retracted and revisited the next time the group meets because someone's opinion was not included.
Teams with too many "C" types tend to have trouble sticking to their decisions because their decisions never feel quite right. They spend too much time reworking solutions trying to handle all possible scenarios even if the scenarios were not requested by a customer. All of this rework results in missed deadlines.
The highest performing teams are the ones that are composed of all these personality types. These teams just need the right guidance to move from divergence to convergence.
Saturday, October 10, 2009
The National Parks: America's Best Idea: Episode Guide | PBS
THE NATIONAL PARKS: AMERICA'S BEST IDEA is a six-episode series on the history of the national parks, directed by Ken Burns and written and co-produced by Dayton Duncan.
Thursday, October 8, 2009
Coconino Loop (report and live coverage) - Mtbr.com Forums
Coconino Loop (report and live coverage) Passion
Wednesday, October 7, 2009
Tuesday, October 6, 2009
Fundamental Cultures of Working Part 2
The downside of the cultivating culture is that employees are mostly concerned with their own interests. Deliverables and deadlines are not high on the list of importance. Teamwork only happens if helps the individual.
The collaboration culture is about teamwork. Teams work together to come up with ideas and solve problems. The team utilizes the wisdom of all team members to make the best decisions.
The book talks about how a collaborative culture can build a sense of community where people are motivated to move past conflict into productivity, move past indecision into action, move past defensiveness into trust.
If you can't tell from reading my post so far, I am very biased towards a collaborative culture. The book says that if you want to have a collaborative culture then it is good for the manager to be passionate about collaboration.
The manager tries to build a highly integrated and self organizing team that can find its own path to success. The team should come to value participatory decision making, self-discipline, and self-organization.
To me this sounds like a big project to take on. I am excited to try it though. I believe the effort I put in will be worth the pay off and then some.
Monday, October 5, 2009
Fundamental Cultures of Working
Command-and-Control— The leader is in charge and makes decisions for the team to ensure tight authority and responsibility.
Competence— The team or project relies on the expert capabilities of the few to bring about success for the whole.
Collaboration— Decisions are consensus-driven, and the team works in partnership toward success.
Cultivating— Establishing personal and professional improvement for each team member is paramount.
The book mentions that some of the downsides of command and control are that the success of the project rests solely on the shoulders of the manager. In addition this culture ruins morale and reduces motivation and creativity.
Since I assumed the manager role on my team, I have had a couple people tell me that I need to take on more of a command and control approach. I am not sure yet that I want to do that. I am interested in reading more about these other approaches. I am glad I picked this book.
I will add some more comments about the other cultures next time.
Thursday, October 1, 2009
How Ironic
For starters I am dusting off this blog and starting a new book today called Collaboration Explained by Jean Tabaka.
I will try to post comments about the book as I read through it.
Wednesday, September 30, 2009
Tuesday, September 22, 2009
Thursday, September 17, 2009
Still forever changed
I finally took him out today, the 2004 Ibex Corrida "Luxe Tour" bike that I call Roadie. Our rides are few and far between these days. Today I pumped up the tires from 10 psi - that's how long he's been sitting. I'm generally just a phone call away from listing him in the freebie classified ads, but every time we go out for a ride, I can't remember what about him made me think he was such a junker. He's a perfectly competent bike. I want to believe in him.
Also today, I picked up from the bike shop the 2008 Surly Karate Monkey that I call KiM. After dropping her off a cliff on Monday, I had to get the brake lever fixed. I also had them swap out her suspension fork for a rigid one. This weekend, I'll outfit her with skinny tires and my bikepacking gear, and shore up Roadie with a few new cables, brake pads, and a rack, all in preparation for the grand fall tour, the Golden Circle. I hyped up this trip enough to convince fellow enduro-nut John Nobile to come all the way out from Connecticut. I told him he would experience "real Alaska" (even though 90 percent of the route is in Canada), complete with wind, cold rain and maybe even a little September snow. We're setting out to relive our Tour Divide glory days on some of the most remote pavement you can find in North America.
Doing all of this started me thinking back to the Tour Divide. It's been exactly two months since I returned to Juneau. It's amazing to me it's only been that long. It feels like I've been "off the road" for ages, settled back into the mainstream of my life like I never even diverged from the flow. Still, little changes from the summer linger. A few ways I am different:
Wednesday, September 16, 2009
Tuesday, September 15, 2009
NHibernate Testing with SQLite in-memory DB
This is a follow-up to my post here about SQLiteDatabaseScope, a small class to control the lifecycle of SQLite in-memory databases. It allows you to run NHibernate tests against SQLite’s fast in-memory database. Since each test can have its own database in memory, you can easily run tests in parallel without conflict.
Friday, September 11, 2009
Tuesday, September 8, 2009
Sunday, September 6, 2009
Wednesday, September 2, 2009
Tuesday, September 1, 2009
Friday, August 21, 2009
Thursday, August 20, 2009
Japan Going Small
With the economy spiraling downwards each day, more and more people are choosing to drive cars that are efficient in fuel use. In Japan, there’s very little parking space and the rising costs of fuel are not going to make things easier. However, even before the Europeans and Americans started building mini cars, the Japanese have already started patronizing their own version of city cars called Kei.
The first thing that you would notice with Kei cars is their size. It’s so small that other minis would look like Goliaths when placed near them. These cars can be found all over Japan, which started during WW II. During that time, all resources were scarce including metal, rubber, and oil. In order to compensate for that, small cars were built that would still deliver the goods despite of their limited size.
The fact is, these Kei cars are freakishly fuel efficient while releasing only very small emissions. In order to be considered a Kei car, it should never be more than 11-feet long, 4.6-feet wide, and 6.5-feet high. Aside from that, the engine should be no more than 660 cc. The fact is, it’s really small, but if you’re only running errands and driving around the city, why would you need anything bigger?
Even Kei trucks are small, but that does not mean that they lack the power that you need. The Kei car pretty much helped the Japanese industry get back to its feet after the war. That’s because with a thriving automotive industry, the whole society will be moving again and that means the enterprise will start pouring in much-needed cash.
Today, these Kei cars are
Tuesday, August 18, 2009
Monday, August 17, 2009
Tuesday, August 11, 2009
Thursday, August 6, 2009
Tuesday, August 4, 2009
Southern New Mexico
The first thing I saw when I woke up in the morning was a baby bird, dead in the grass just inches from my face. Above me, an adult robin, presumably its mother, hopped frantically from branch to branch, screeching into the still air. I stood up quickly and moved my bag away from the scene of the accident, which just riled up the distraught mother even more. Morning sun filtered through tall ponderosa pines. The baby bird laid lifeless on its side. And I was on such an emotional edge at that point in the race that I just broke down bawling. It was so sad - the dead baby, the despairing mother, and an unknown tragedy that seemed to occur while I slept in ignorant bliss.
Monday, August 3, 2009
Friday, July 31, 2009
Thursday, July 23, 2009
Unsubscribing made easy
Posted by Brad Taylor, Gmail Spam Czar
We believe you should only get the mail you want to get. Some of you already use the "Report Spam" button on all kinds of unwanted email, and for that we're very thankful: the more spam you mark, the better our system gets at weeding out junk mail.
Unsubscribing from mailing lists and newsletters you subscribed to a while back but no longer want to receive should be just as easy. Searching through individual messages for little unsubscribe links is too big a pain —you should be able to unsubscribe with a single click.
So we just launched something that makes this all work better, both for Gmail users and big email senders. Now, when you report spam on a legitimate newsletter or mailing list, we'll help you unsubscribe. After clicking report spam, you'll see a little dialog like this:
Clicking "Unsubscribe" will automatically send a request back to the sender so they'll stop emailing you.
This only works for some senders right now. We're actively encouraging senders to support auto-unsubscribe — we think 100% should. We won't provide the unsubscribe option on messages from spammers: we can't trust that they'll actually unsubscribe you, and they might even send you more spam. So you'll only see the unsubscribe option for senders that we're pretty sure are not spammers and will actually honor your unsubscribe request. We're being pretty conservative about which senders to trust in the beginning; over time, we hope to offer the ability to unsubscribe from more email.
For those of you senders who are inte
Teams should be improved, not enlarged
Here is a common problem: A manager has a 10-person team that sits close together and achieves high communication rates with little energy.
The manager needs to increase the team's output. He has two choices: add people or keep the team the same size and do something different within the team.
If he increases the team size from 10 to 15, the communications load, communications distances, training, meeting, and documentation needs go up. Most of the money spent on this new group will get spent on communications overhead, without producing more output.
This group is likely to grow again, to 20 people (which will add a heavier communications burden but will at least show improvement in output).
The second strategy, which seems less obvious, is to lock the team size at 10 people (the maximum that can be coordinated through casual coordination) and improve the people on the team.
To improve the individuals on the team, the manager can do any or all of the following:
* Send them to courses to improve their skills.
* Seat them closer together to reduce communications cost.
* Improve their amicability and teamwork.
* Replace some of the people on the team with more talented (and more highly paid) people.
Repeating the strategy over time, the manager will keep finding better and better people who work better and better together.
Notice that in the second scenario, the communications load stays the same, while the team becomes more productive. The organization can afford to pay the people more for their increased contribution. It can, in fact, afford to double their salaries, considering that these 10 are replacing 20! This makes sense. If the pay is good, bureaucratic burden is low, and team members are proud of their output, they will enjoy the place and stay, which is exactly what the organization wants them to do.
As a programmer and not the manager how can I help our team improve? Hopefully reading this book is a start, but I am going to keep looking for ways to do more.
Tuesday, July 21, 2009
Monday, July 20, 2009
Designing a methodology
Designing a methodology is not at all like designing software, hardware, bridges, or factories. Four things, in particular, get in the way:
* Variations in people. People are not the reliable components that designers count on when designing the other systems.
* Variations across projects. The appropriate methodology varies by project, nationality, and local culture.
* Long debug cycles. The test and debug cycle for a methodology is on the order of months and years.
* Changing technologies. By the time the methodology designer debugs one methodology design, the technologies, techniques, and cultures have changed and the design needs updating.
No wonder it is so hard to get this stuff right. It keeps things interesting though.
Friday, July 17, 2009
Wednesday, July 15, 2009
Tuesday, July 14, 2009
Extreme Hour
More recently, Peter Merel invented a one-hour process miniature for Extreme Programming, giving it the nickname Extreme Hour. The purpose of the Extreme Hour is to give people a visceral encounter with XP so that they can discuss its concepts from a base of almost-real experience.
In the Extreme Hour, some people are designated "customers." Within the first 10 minutes of the hour, they present their requests with developers and work through the XP planning session.
In the next 20 minutes, the developers sketch and test their design on overhead transparencies. The total length of time for the first iteration is 30 minutes.
In the next 30 minutes, the entire cycle is repeated so that two cycles of XP are experienced in just 60 minutes.
Usually, the hosts of the Extreme Hour choose a fun assignment, such as designing a fish-catching device that keeps the fish alive until delivering them to the cooking area at the end of the day and also keeps the beer cold during the day. (Yes, they do have to cut scope during the iterations!)
This sounds awesome. I wish we had done an extreme hour on my team before we started XP. I wonder if I could convince people to do one now.
There are so many different pieces to XP. It is hard to see how they fit together by reading a book. I think the Extreme Hour could show people how each part of the process is important without making them invest more than an hour.
Tuesday, July 7, 2009
Friday, July 3, 2009
Daily Commute started on July 1, 2009
Starting yesterday, I am doing my daily work commute via the Twike. The missing piece was getting a second battery pack working well. I drove yesterday and today to and from work which for me is just under 8 miles. I don't yet have a good feeling for how much power it is taking to do my commute but today it only took 1.2Kw to charge it when I got to work (and that was after it ran the fans for a while to cool the batteries). The NiCads can deliver lots of power but they do heat up in doing so and right now we are having a heat wave in Portland which does not help. I got lots of thumbs up and waves today. One guy was keeping next to me and yelling out his open windows. "hey! really cool. Where did you get it? Did you build it?" that kind of stuff. Kind of hard to drive and answer questions in traffic. Work is cool about letting me charge there (used 12 cents of power today). I'm not sure, but I might have enough charge to go roundtrip without charging at work. Tomorrow I'm going to try a trip to someone's house that is 13 miles away so we will start to test the range a little more. Currently, my longest single trip is the 8 miles to work. Since I brought it home, I bought 3 new tires, had them mounted and balanced, and I installed them on the vehicle. I also did a lot of cleaning up in the battery compartment and on all the removeable panels (bottom and sides). With two reasonable battery packs, the car is pretty snappy on acceleration. I can keep up with traffic no problem and can even hill climb at a reasonable rate (not as fast as a car but at least I *can* accelerate uphill now). I have been taking a less direct route home to minimize the hill climb t
Thursday, July 2, 2009
Coordination is important
Coordination is important. The same average people who produce average designs when working alone often produce good designs in collaboration.
Conversely, all the smartest people together still won't produce group success without coordination, cooperation, and communication. Most of us have witnessed or heard of such groups. Team success hinges on cooperation, communication, and coordination.
I like this quote. This is the reason why I am reading this book. I want to learn how to help myself and my team cooperate, communicate, and coordinate better.
Wednesday, July 1, 2009
Amicability and Conflict
Amicability is the willingness of people to hear the thoughts of another person with goodwill and to speak without malice.
Amicability is the weaker cousin to trust. Trust is wonderful and should be nurtured, but amicability is easier to achieve within a group and still confers advantages. I always watch the amicability level in an organization to learn to what extent information is being revealed versus concealed in conversations.
When people conceal information from their colleagues, they lower the rate of information discovery, which raises the lost-opportunity cost as well as the overall cost per idea developed.
Amicability permits successful conflict to occur when the project goes through a stressful period. The people, knowing that the others are not intending to be hurtful, can look past the current disagreement toward resolving the issues.
One might think that removing all conflict from a project team would be the best, but that turns out not to be the case. People need to be able to disagree, in order to identify design problems!
I think being able to listen and without an agenda is really important but really hard for me to do. I start thinking about how to word my response before the other person is even finished talking. I want to be more patient and not be in such a hurry to steer the conversation in one way or another. I need to trust that eventually both people working together will come to the best conclusion.
Tuesday, June 30, 2009
Expectations and Citizenship
There is an interesting and relevant aside to mention about this group, having to do with expectations and citizenship. For reasons I won't go into, this team of business analysts thought they were supposed to work in the XP style and that XP prohibited them from writing things down.
Notice four things about their situation:
1. They misunderstood XP. It does not forbid people to write things down.
2. Their citizenship was so strong that rather than be poor citizens and write down their thoughts on the domain model, they chose to be good citizens and not write down their business model at all!
3. Actually, they knew that the project wouldn't succeed if they really wrote nothing down. So they each clandestinely wrote pseudo use cases and other notes, which they passed to the programmers. They still did not create a domain model for themselves.
4. By writing down those notes, they subverted their own (mistaken) interpretation of the official process. I find this situation particularly interesting, because they were at war with themselves about whether to be good citizens and follow the process (at the expense of the project) or to be good citizens and protect the project (by violating the process).
What was significant in the end was that they posted an information radiator on the corridor wall, on which they scribbled individually and as a group, to give their thoughts and decisions some stickiness.
I feel like I have been in this situation before. I want to do the right thing, but I don't know what the right thing is. I often wonder if I am shooting myself in the foot by trying to be too strict with my attempts to follow the XP recommendations. I guess it would be helpful to have an Agile coach to talk to.
Monday, June 29, 2009
Repairing Design Discussions
On project "Winifred" (Cockburn 1998), the lead programmer announced at regular intervals that design was unnecessary and that code simply grew under his fingertips.
As a predictable result, the young programmers working in the room with him also felt it unnecessary to design. The code looked that way, too.
He eventually left and I took his place. To reverse the situation, I arranged for us to design by having conversations at the whiteboard. After some period of doing this, I started getting questions like, "Could you look at the responsibilities (or communication patterns) of these objects?"
By setting an audible tone in the room and making these design discussions legitimate and valued, the programmers started to converse about design together.
We struggle with these discussions on my team. I want to have these discussions, but I have a hard time getting everyone to participate. There are a few vocal members on my team that complain that our efforts to design as a group are unnecessary. I wonder if there are ways to work through this problem without losing team members.
Saturday, June 27, 2009
Program by example
You can and should start taking advantage of people's strengths in copying and altering work samples. Create a small, online library of real samples for work products produced on your (or some previous) project. Other people can then simply copy one of the samples as the base for their own work. In copying it, they will pick up both the structure and style from the sample, while changing the details to fit their purpose.
The implication is, of course, that you would like the work samples you collect to be relatively "good," having structure and style you don't mind having copied. They don't have to be perfect, of course, just "good enough."
I cut and paste code all the time. I think I have a catalog in my head of all kinds of patterns of solving problems. I wonder if people would use a WIKI site with code examples instead of cut and pasting from the codebase?
Friday, June 26, 2009
Piattelli-Palmarini describes a number of experiments involving risks and rewards. The interesting thing is that even when the outcomes are mathematically identical, the results are different depending on how the situation is presented.
Illusions of Choice
Piattelli-Palmarini cites a dual experiment. In the first, people are given $300 and then have to choose between a guaranteed $100 more or a 50/50 chance at $200 more.
People prefer to take the guaranteed $100.
In the second, people are given $500 and then have to choose between having $100 taken away from them or a 50/50 chance of having $200 taken away from them.
People prefer to risk having $200 taken from them.
(Piattelli-Palmarini, p. 58)
Mathematically, all outcomes are equal. What is interesting is the difference in the outcomes depending on how the problem is stated.
Piattelli-Palmarini sums up the aspect relevant to project managers: We are risk-averse when we might gain.
and then later
This characteristic, "preferring to fail conservatively rather than to risk succeeding differently," gets coupled with people's fear of rejection and the difficulty they have in building new work habits. The three together explain (to me) why managers continue to use the long-abused one-pass waterfall development process. Based on this line of thinking, I expect that people will continue to use the waterfall process even in the presence of mounting evidence against it and increasing evidence supporting incremental and iterative development. Use of the waterfall process is anchored in a failure mode.
Our group has been trying to practice XP for over a year now. I like it, but I think it is going to be a long hard journey to get some people to try this.
Wednesday, June 24, 2009
Repositories And Abstract Classes
I couldn't find anything in the big blue book or online so I made something up. I have one Repository for the base class. Then each GetByXXX method is a generic method that takes the type of objects you expect to get returned. So you can get a list of the base classes or a concrete type or an interface that allows you to group concrete types together.
Them's Funky People
There is some resistance in our industry to the idea that people factors dominate software development.
As I participated in initiatives for formal program specification, advanced programming environments, and new development processes, I kept discovering that successful teams were still delivering software without using our latest energy-saving ideas.
Initially, I viewed this as a nuisance: "Why can't those people just realize how much better off they would be if they used our ideas?!"
Eventually, it went from a nuisance to a curiosity.
Slowly, it became a discovery.
I reversed my assumptions and found that the opposite correlation held: Purely people factors predict project trajectories quite well, overriding choice of process or technology.
I found no interesting correlation in the projects that I studied among process, language, or tools and project success. I found successes and failures with all sorts of processes, languages, and tools.
A well-functioning team of adequate people will complete a project almost regardless of the process or technology they are asked to use (although the process and technology might help or hinder them along the way).
I need to remember this. Put the people above all else.
Monday, June 22, 2009
Wednesday, June 17, 2009
Thursday, June 11, 2009
Saturday, June 6, 2009
Saturday, May 30, 2009
Tuesday, May 19, 2009
Monday, May 11, 2009
Ecogo
It has been a while since I have passed along any of the entries from last year’s “commuter bike for the masses” design competition. I have been busy with other things, but I do still have quite a few of the entries to share. As a follow up to my last post, I will show you one more of the velomobile entries that we received…ecogo by Walter Graf.
Here is what Walter had to say about his design:
“ecogo is a concept recumbent bicycle designed to get commuters out of their cars and onto - or into - bikes. The recumbent features a reverse-tricycle design to keep it stable and take the balancing act out of riding a bike. With its laid-back seat and ergonomic pedalling position, the rider / driver can relax and take it easy while pedalling. The bike will stay upright even when going up hills slowly in the "granny gear."
The carbon fiber and formed plexiglass shell protects the rider / driver from the elements, just as a car would, so this can no longer be an excuse for not biking. Its aerodynamic shape reduces the drag from the wind, which, along with the low profile, make riding at high speeds much less tiri
Saturday, May 9, 2009
Mark Twain Motivational Posters | Sloshspot Blog
Sloshspot is the place on the web to search for nightlife spots, bars, pubs and clubs in Lawrenceville. Search our directory for nightlife and entertainment venues in Lawrenceville that match your interest. Check out whats going on in Lawrenceville tonight!Mark Twain Motivational Posters: The Sloshspot Blog is the number one blog for nightlight and partying the world over...
Friday, May 8, 2009
The Lincoln C Concept: The Green Car with the Luxury Feel
It must have been quite the surprise to auto enthusiasts when Lincoln presented the Lincoln C Concept car. While most people are hesitant to make the shift from their gas-guzzling rides to the smaller and greener vehicles on the market, it should come as a comfort to luxury-loving folks that they won’t have to give up the comfort provided by their luxury rides–not once the Lincoln “C” Concept hits the market.
Wednesday, April 15, 2009
Sunday, April 12, 2009
Thursday, April 9, 2009
Tuesday, April 7, 2009
Sunday, April 5, 2009
Monday, March 30, 2009
Saturday, March 28, 2009
Friday, March 27, 2009
Friday, March 20, 2009
Tuesday, March 17, 2009
Monday, March 16, 2009
Tuesday, March 10, 2009
Monday, March 9, 2009
Thursday, March 5, 2009
Tuesday, March 3, 2009
Ant trails, bike trails and Contrails
Like ants leaving a scent trail for other ants to follow, cyclists can follow the trail of other cyclists with the Contrail Biking Community Tool designed by Pepin Gelardi and Teresa Herrmann for a competition.
A doodad deposits chalk powder on the rear tire, which in turn leaves a trail of chalk on the road showing the bicycle's path on the road.
As more cyclists ride along the chalk marked route, the routes become more visible to cyclists and motorists, just like ant trails are reinforced as more ants use the path.
I really like this, though I hope I'm not directly behind a cyclist using one of these -- it could be pretty bad for the asthma. Doobybrain describes this concept as useful for showing cyclists where to "ride safely and out of the way of vehicular traffic," but the illustration above accurately portrays that the safest place can be in the lane with vehicular traffic if lane width warrants it. Gutter bunnies are dead bunnies.
More discussion at Bike Hacks and Streetsblog. Hat tip: Jamie in Columbus.
Monday, March 2, 2009
Sunday, March 1, 2009
Thursday, February 26, 2009
Wednesday, February 25, 2009
Tuesday, February 24, 2009
Sunday, February 22, 2009
Tuesday, February 17, 2009
Sunday, February 15, 2009
Amazon.com: Kindle 2: Amazon's New Wireless Reading Device (Latest Generation): Kindle Store
Amazon.com: Kindle 2: Amazon's New Wireless Reading Device (Latest Generation): Kindle Store
Thursday, February 12, 2009
Kingsford is on fire!
Meet "Kingsford" the piggle. He is the most anerable house-pig you've ever seen. Squealing included:
Great find, NTMTOM. Via LA Times.
Wednesday, February 11, 2009
Why not get a "Pomster"?
YOU HAVE NO REASON WHY YOU SHOULDN'T GET ONE
[shifty eyes] I'm still checking if they exist. Something about the beady-eye to paw ratio scares me.
This pocket pet pomster was created by Scuzzi for a contest. No, you can't have one.
Monday, February 9, 2009
Sunday, February 8, 2009
Wednesday, February 4, 2009
Sunday, January 25, 2009
Ladies and Gentlemen, THE PERFECT SCHNOZZLE
[Handing piglet blule-ribbon award] Dang, piglet, you win theBest of Schnozzles. We don't even have to wait for the Schnozzle awards in March. This competishe is OVER. [clapping hands in 'done' motion]
Can you lift your head up a little bit there to show us the GOODS?
Thanks.
Oh you knew I was gonna do this.
Stand back. It's for your own good.
SCHNOZZHANCE!
Runt piggle "Chester" LOVED burying himself in heaps of laundry. Photos by the fabulous Kristine B.
Friday, January 23, 2009
Audio Books: Download free audiobooks at LibriVox
Web site LibriVox offers free audiobook MP s of books in the public domain We've posted about the all-volunteer LibriVox
Thursday, January 22, 2009
Does this look like me?
Carl in Longmont, Colorado says this looks like me.
This illustration is from the "winter" collection by artist Yuzuriha Satoshi in Tokyo, Japan. This illustration entitled "Koshu Kaido / Inume" shows a stop along the old "Koshu Highway."
Satoshi-san is probably a randonneur. Many of his prints illustrate what a long distance cyclist may see while riding.
In his cyclist gallery and his seen gallery, Satoshi follows the Haiku tradition of splitting his illustrations into seasons: Spring 春, Summer 夏, Autumn 秋 and Winter 冬. Go take a look -- it's good stuff.
Chris @ Velo Orange just told me he posted about this also.
Monday, January 19, 2009
Top 10 Steve Jobs Quotes « Marketing Nirvana
We don’t get a chance to do that many things, and every one should be really excellent. Because this is our life.
Life is brief, and then you die, you know?
And we’ve all chosen to do this with our lives. So it better be damn good. It better be worth it.
Friday, January 16, 2009
swissmiss: A bike lane that travels with you
If there is no bike lane, what to do? Bring your own: LightLane . We agree with GOOD, this is a superb idea. (thank you rion)...