This is the last and final part on my SpringOne 2009 experience. It’s late catching up to the 3 earlier posts but it’s here now. This post summarizes the sessions I attended from day 4 and wraps up with a summary of my take aways. If you want to catch up here are the three earlier posts:
Read on for day 4.
Siri, which debuted last week, is surely the first iPhone app that’s the commercialized result of a multimillion-dollar Defense Department research project. It’s a “virtual personal assistant” that uses voice recognition, your GPS location, and links to local information and services to respond to requests you speak into an iPhone 3GS.
You can ask Siri to call you a taxi, or to reserve a table at the best nearby sushi joint, or to tell you who’s playing at a local concert venue. The voice-recognition part works just about perfectly. And it all feels like a sneak preview of how we’ll get and use information in the future, even though I’m occasionally disappointed by the results (Siri occasionally recommends local businesses based on skimpy data.)
Last year I coordinated a technical book club here at Source Allies. This was my first experience doing one and I wanted to share my experience for the benefit of others who may be looking at starting one.
The fact that we even started a book club was a big positive because it is one great way to geek out with very smart people. You get the opportunity to voice your opinion on a certain topic and hear counter-points or similar views that expand your own perspective. » Read more: Running a Technical Book Club – Take 1
I recently ran across the following article on a blog:
A Japanese company (Toyota) and an American company (General Motors) decided to have a canoe race on the Missouri River. Both teams practiced long and hard to reach their peak performance before the race. On the big day, the Japanese won by a mile.
» Read more: A Modern Parable
January 25th is an important day… it’s not a holiday, it’s not a paid day off… it is…
The
L o n g e s t
and
most depressing
day of the year
It seems the Black Screen of Death has struck again. Microsoft isn’t confirming or denying that the issue was caused by a Microsoft update, but this issue is not new to Windows users. It affects all breeds of Windows OS, after logging in the screen goes black. Some users are able to bring up the task manager by doing a ctrl + alt + delete. Prevx (A security company in the UK) has provided a possible fix. Prevx released a statement about this issue:
“The cause of this recent crop of Black Screen appears to be a change in the Windows Operating System’s lockdown of registry keys,” wrote Kennerly. “This change has the effect of invalidating several key registry entries if they are updated without consideration of the new ACL rules being applied. For reference the rule change does not appear to have been publicized adequately, if at all, with the recent Windows updates.”
Here are the recommended steps
You have a 1 in 10 chance that this will actually work.
For all the positives that updates have to offer the truth remains that the results can sometimes be undesirable. Security patching is a must and I would never recommend not performing updates. The wise engineer will image his or her disk or make some other form of reliable backup before performing updates. Unfortunately as shown with this issue, the negative effects may take a couple of weeks to surface, and in a production environment rolling back to an image is not an option.
While searching through quotes to include in our company newsletter, I came across this:
“Any fact facing us is not as important as our attitude toward it,
for that determines our success or failure”
Read that again…
“Any fact facing us is not as important as our attitude toward it,
for that determines our success or failure”
The mind is a very powerful thing. For example, I don’t believe I’m the only one to experience being in a store next to a visibly sick individual and after they sneeze I start to feel like I’m getting sick. It’s impossible to get sick that quickly but my mind starts thinking of the possibility of catching the virus this stranger had… and how I have so many plans, I can’t be sick… what am I going to do… and instantly I start to think that I’m sick. The mind has the ability to quickly convince us something is happening that isn’t!
The thoughts in your head, positive or negative, directly affect your attitude. Your attitude directly affects how others react to you. Those closest to you, your family and your co-workers, are able to tell what type of thoughts are going through your mind by a simple look at your face and they react accordingly.
So what is my point? Take a self inventory! Are most of the thoughts that go through your mind positive or negative? The situations that you face on a daily basis are NOT as important as how you decide to handle them. When a difficult situation arises and you start to see it in a negative light, remind your self…
——————————————-
“Any fact facing us is not as important as our attitude toward it,
for that determines our success or failure”
-Norman Vincent Peale
——————————————-
Think positively… Aim for success!
You may be amazed at the outcome when you do!
If you’re a nerd like most of us here at Source Allies, you probably think robots are cool. One of the most important part of robotics is teaching the robot to find its location on a geographic map – a process known as “localization.” One such algorithm for solving this problem is known as Monte Carlo Localization. When talking about this algorithm, we typically use a a notion commonly referred to as “particles.” These particles generally can be thought of as virtual manifestations of the robot within some computer. They are postulations about the robot’s location, orientation, and certainty of this information on a geographic map. With that in mind, the Monte Carlo Localization algorithm in plain English is as follows:
So that was a very basic, watered down version of the algorithm that omits many important statistical calculations, but hopefully it gets most of the main idea across.
In case there is any confusion, let’s walk through an example. Let’s say I am a robot. For obvious reasons, I was kidnapped by some ninjas. The ninjas then released somewhere in downtown Des Moines I have no idea where I am at first. Fortunately, I am a robot and have a perfect map of downtown Des Moines, so I initialize in my head a set of postulations about my position and orientation. These beliefs are completely random and distributed fairly evenly over all of downtown Des Moines and all have different random orientations.
First thing I do is open my eyes and look around, perhaps I’ll take a few steps in any direction and continue gathering visual information. I see a Smokey D’s. Then I look at all the particles in my set of particles and determine which of those particles also would see a Smokey D’s. I decide that those particles are better than all the other particles and assign them greater weights. Then I go through my set of particles again do some ninja-statistics that I learned while I was kidnapped to decide which particles can make it to round two and which cannot. What I’d end up with is two clusters of particles around the two points, appropriately titled “A” and “C.”
There would be a cluster of particles around A and C
Then I’d go back to step 2, interact with my environment some more, find out that I’m actually indoors and that fits better with the particles around A – the Smokey D’s in the skywalks. Perhaps I’d repeat from step 2 a few more times and eventually weed out particles until I have a full set of particles that are all in a very similar spot around the Smokey D’s in the Skywalks. Then I know where I am and I’m a happy robot.
Everyone, especially project managers, is in love with Agile Development. And why wouldn’t they be? Under the old school system, you’d end up with developers either sitting around uselessly, or drafting up prototypes that will only be thrown away. Agile allows for parallel design and development, wasting less time and money. But there’s always a tradeoff. In this case, I’m thinking of commonality of design. Let me explain by example:
I’m currently working an Agile project with three developers including myself. We’ve divied up the tasks so that one is doing the JSF database plumbing, and the other two are creating the web services that sit on the back end. We started development without having a certain idea of certain database keys, so we naturally wrapped the keys in an object that we could easily change when the decision was made. It let us move forward with development and had a very low cost for change when business came back with a decision. But we each implemented it in a difference way, using a different nomenclature and at different times. So now we have three objects that perform identical tasks, and require a translation process when our respective parts interact with each other. It’s not broken, but it’s definitely messy.
And it’s a natural fallout of the tendency to think that Agile means you start developing right away, and things like requirements and interfaces can be laid on top of the code later. How do we prevent it? Sadly, communication is the only answer. Code reviews early on could have prevented this situation before it would have been a pain in the tuckus to refactor. A project wiki exists, and even has a section that lays out common objects and interfaces. But the wiki was infrequently referenced for matters of actual code implementation; it was for the documents and the Agile storyboards.
In the end, it’s important to recognize that Agile development has taken the large chunk of communication out of the beginning phase of a project. But that communication isn’t gone, it’s been spread out over the duration of the project, and in most cases that means there going to be a lot more of it. As developers we eagerly embrace Agile projects since it means we don’t spend two months in design meetings and can’t indulge our love of code early on, but we have to realize that it comes with a cost. We actually have to talk to each other.
After several weeks of performing support duties at a larger company I have begun to wonder about support practices and what could make the process better.
The process in which I currently work goes as follows:
• Field employees call the marketing team and describe the problem.
• Marketing team calls the Help Desk and re-describes the problem.
• Help Desk creates and issue ticket and assigns the ticket to a team.
It seems like there might be a quicker option.
My responsibilities include monitoring all the tickets that come to our team, solving what I can, and passing on ones for other applications. Frequently these tickets are mis-assigned or contain incomplete or inaccurate information which only creates more work for the support team. Because our support team does not contact customers, if we need more information we must go back through the support team.
I’m sure there are ways to improve this process, but I’m curious what other peoples experiences are with support processes at larger employers.
© 2010 Source Allies Blog · Proudly powered by WordPress & Green Park 2 by Cordobo.
Valid XHTML 1.0 Transitional | Valid CSS 3
