Using NHibernate With Stored Procedures - Ayende @ Rahien

link -> Using NHibernate With Stored Procedures - Ayende @ Rahien

I wonder if you could use something like this to do shift collation. The advantage being that another entity could map a PunchedShift as a reference instead of just a PunchedShiftID. I would rather it let me write code instead of SQL though.

A Sample Format for a Spreadsheet-Based Product Backlog

link -> A Sample Format for a Spreadsheet-Based Product Backlog

I want to show a real easy way to put user stories in a spreadsheet-based product backlog. I wrote this after seeing someone tweet a screen capture of a product backlog I made 9 years ago and thought to myself, “Yikes, that’s out of date for how I do it today…”

As you probably know I’m a big fan of writing the product backlog in the form of user stories and of writing user stories in the form, “As a , I so that .” An example being, “As a frequent flyer, I really want to be able to connect to the internet while flying so that I can update my blog while traveling rather than having to save this as a text file and updating my blog later.” (Can you guess where I am while writing this?)

What I’ve found makes a user story in this format very easy to work with in a spreadsheet is to take the boilerplate parts and put them into column headings. So we’ll have column headings like “As a” and “I” and “so that”. The meat of each story is then clearly visible in each row. Additional columns can be added for things like a unique identifier, notes, status and such. In this example, I’ve also included a column for the theme or grouping of which the story is a part. You can see this in the screen capture below. You can click the image for a larger view.

It is nice the way it groups who the story is for. Unless of course all the stories are for the same person.

Jetty Startup Problems Due to Entropy

link -> Jetty Startup Problems Due to Entropy

On the MMO I’m working on, we do quite a bit of service monitoring via jetty.  Things like having a URL that reports back version information for a component, or a page full of statistics showing recent activity, or a way to trigger a self-check in a component to determine if the component is sane and healthy or not.

For certain components we run multiple instances of the service on the same box.  In development environments, it’s a pretty small number of instances.  On a production environment it’s a much bigger number.  Typical stuff.  However Operations noticed that startup times for a server full of instances jumped from seconds to over 20 minutes when the number of instances was increased from 3 to 12.  Ouch.

So, something is blocking on startup.  After some digging, I came across this post explaining how jetty uses a secure random number generator for session ids, which is based on the pool of entropy generated by the system.  Sure enough…

$ cat /proc/sys/kernel/random/entropy_avail
128

(On development cluster machines that value is upwards of 3000)

Since we don’t care if the jetty session IDs are securely generated or not, switching the generator from secure to not-secure took us back to a few seconds to start up 20 instances.

If only this made rpweb start up faster

A Different Kind of Technical Interview

link -> A Different Kind of Technical Interview

Based on how much candidates and interviewers both seem to enjoy this, I hardly see any reason to do a whiteboard interview at all anymore. Personally, I don't even look a resume before I do a pairing exercise with a candidate. I don't feel the need to know anything about someone going into it, and I feel like I learn all I need to spending two hours with them on a task.

If you're having trouble hiring good programmers, give it a shot. Replace part of your interview process with a pairing exercise and see if it makes a difference.

Sounds like a fun interview.

Stream(SQL) Event Processing with Esper

link -> Stream(SQL) Event Processing with Esper

What if we turn the problem on its head: instead of storing data and then executing batch queries over it, what if we persisted the query and ran the data through it? That is the core idea and insight behind Event Stream Processing (ESP) systems: store queries not data, process each event in real-time, and emit results when some query criteria is met.

Sounds like more fun than file imports.

Everybody Loves The Buildmanager

link -> Everybody Loves The Buildmanager

 

 

Tweet

Awesome Real-Life Chewbacca Dogs

link -> Awesome Real-Life Chewbacca Dogs

With all the dog breeds out there, you're bound to come across a few that look like Chewbacca from Star Wars. We've rounded up the most popular look-a-likes for your viewing enjoyment. Click here for the first picture in gallery. Continue reading for a video.

[Sources 1 | 2 | 3 | 4 | 5 | 6]

There’s I(ntelligence)Q, and then there’s I(nfluence)Q

link -> There’s I(ntelligence)Q, and then there’s I(nfluence)Q

People who work in software are smart people who take pride in their abilities to understand complex information and solve difficult problems. But much of the work isn’t only about smarts. Creating most software requires the help and cooperation of other people. Telling, convincing, and winning arguments won’t work to bring people along, change their minds, or help them help you. That requires influence.

I feel like Brandon in this example and act like Cindy almost every day. Doh. Need to act more like Jason in this example.

MIT students develop liquid fuel for electric cars

link -> MIT students develop liquid fuel for electric cars

Best at argument != Best ideas

link -> Best at argument != Best ideas

Bob may have the best ideas on the team. We don’t really know if that’s the case. No one else’s ideas are fully considered. We do know he doesn’t have a perfect record. Some of his fixes don’t work the first time. Some of his fixes break something else.  If the team had a process to consider and refine ideas, that might not happen as much.

It may sound like it will take more time to separate generating ideas from explaining, exploring, and evaluating them. It may seem like a lot of effort to find more than one idea and test the ideas for soundness and test the level of support for a given idea.

But in years of observing teams, I find that slowing down and separating the steps of the choosing a solution helps the team speed up. A mashup process forced by a dominant individual may appear to save time in the very short-term. That’s seldom true if you account for all the time costs and other effects incurred.

I like the part about separating the stages and having at least three ideas.