Live without desktop tools? - Using free, online tools Word:* Zoho DocsExcel:* Zoho Sheet* EditGrid(http://www.editgrid.com)Presentations:* Zoho Show* 280slides (http://280slides.com)Visio:* Gliffy: ...2010-01-21T09:32:00Z2010-01-21T09:32:00ZJessica.kjmhttp://www.cnblogs.com/kkjmyazi/

纪念逝去的20092010-01-21T09:30:00Z2010-01-21T09:30:00ZJessica.kjmhttp://www.cnblogs.com/kkjmyazi/

An upset men came to wise Socrates and said:"Listen, I have to tell you about your friend...""Wait!" interrupted Socrates."Have you strained what you intend to tell through three strains?" The men won...2009-02-15T10:07:00Z2009-02-15T10:07:00ZJessica.kjmhttp://www.cnblogs.com/kkjmyazi/

在项目的初期，往往通过一次简单的交流、若干原始资料，需要我们能迅速把握系统的整体需求，并明确其中的要点。如何能够有效地做到这一点呢？我通常会使用记事本，做一个包含要点的笔记，这份笔记的内容如下：2007-06-19T14:02:00Z2007-06-19T14:02:00ZJessica.kjmhttp://www.cnblogs.com/kkjmyazi/

公司内部系列沟通能力培训活动的资料ppt共享。1.沟通态度与方式2.团队沟通之会议游戏3.技术管理与沟通2007-06-12T06:43:00Z2007-06-12T06:43:00ZJessica.kjmhttp://www.cnblogs.com/kkjmyazi/

在我们的软件开发过程中，项目启动通常需要：项目建议书或可行性方案评审，项目启动会，项目经理任命书，项目任务书，项目软件开发计划（配置管理计划、测试计划），繁琐不说，关键是最初的规划效率很低，——因为一般项目持续半年甚至一年多，期间物是人非，业务需求更改，所作的很多规划工作回过头看发现没起到任何实质作用。我好奇，敏捷项目是如何启动的呢？因此就有了下面的对话。2007-06-12T01:07:00Z2007-06-12T01:07:00ZJessica.kjmhttp://www.cnblogs.com/kkjmyazi/

一点杂谈和感想。关键词：向上沟通，冲突，水管工和教授，过程管理，周例会2007-05-24T08:03:00Z2007-05-24T08:03:00ZJessica.kjmhttp://www.cnblogs.com/kkjmyazi/

昨天做技术管理内部交流，有位同事提了两个典型的需求故事，说说我的看法。2007-05-24T07:47:00Z2007-05-24T07:47:00ZJessica.kjmhttp://www.cnblogs.com/kkjmyazi/

虽然两人沟通也存在很多不畅的问题，但在我们研发团队中，更多更具挑战的是团队成员间的沟通。当参与沟通的人由2人变成多人的时候，有效沟通变得很困难。如何进行高效沟通，让团队更有战斗力呢？2007-05-15T03:59:00Z2007-05-15T03:59:00ZJessica.kjmhttp://www.cnblogs.com/kkjmyazi/

沟通难有效沟通更难团队有效沟通更是难上加难君不见，邮箱总是一片红，从早到晚看不休， (使用LotusNotes，未读邮件是红色)君不见，会山会海扎堆开，矛盾重重未见改。 君不见，酒桌上，宴席间，杯盏交错喜开颜；君不见，上班后，工作中，满怀心事奈何天。君不见，有情人你卿我爱，天天吵闹要拜拜，君不见，冲突多因沟通起，及时有效尚可为。与君歌一曲，请君为我侧耳听。 有效沟通难，但未难于上青天。齐力倾心改，...2007-05-11T06:32:00Z2007-05-11T06:32:00ZJessica.kjmhttp://www.cnblogs.com/kkjmyazi/

My current project integrates with the Microsoft Dynamics CRM system for managing customer records. We already spiked out authenticating and our next step was attempting to update a record via its “REST Endpoint“.

On retrieving a record, you follow the OData style for finding something of relevant. Updating a record is interesting as we only want to send the fields that need to change remotely. Looking at their sample code, you need to:

• Create an authenticated POST request
• Set the X-HTTP-Method to MERGE
• Set the appropriate content type for the content you intend on sending. In our case, set the header Accept to application/json and the Content-Type to application/json; charset=utf-8

Our end point for a contact looked something like:

https://crm.thekua.com/xrmservices/2011/organizationdata.svc/ContactSet(guid'867dc3f2-909e-e111-9912-0050569c2d72')

.

Updating simple fields off a contact is easy. We post something like:

{
  "EMailAddress1":"spike.jones4@gmail.com",
  "MobilePhone":"33335"
}

We receive a HTTP 204 (No Content) on a success. Posting an invalid attribute (i.e. one that does not exist on the ContactSet such as “EMailAddreXXXs1″) results in a HTTP 400 (Bad request) and a nice description about what’s wrong. You will also get a HTTP 400 if you post the wrong datatype such as sending a string where they expect a number. If you pass invalid values (but of the correct datatype) for a field, your response is a HTTP 500 with a message like The value of 'gendercode' on record of type 'contact' is outside the valid range."

Updating Option Set Values

Updating simple datatypes is easy and obvious from a JSON point of view. You have a couple of complex datatypes, such as the standard GenderCode. When you query for a record, you get back something that looks like

{"GenderCode"=>{"__metadata"=>{"type"=>"Microsoft.Crm.Sdk.Data.Services.OptionSetValue"}, "Value"=>1}}

To update something like this, you need to send a nested JSON object. The example follows

{
  "EMailAddress1":"spike.jones4@gmail.com",
  "MobilePhone":"33335",
  "GenderCode": {
    "Value" : "1"
  }
}

A HTTP 204 (No Content) response indicates a success. Viola!

It's been recently brought to my attention that I don't view open-source the way that many of my friends do. My attitude has always been: Here's some code that works well for what I want. If it works well for what you want, great! If not, I'm willing to make changes that improve the library; however, I'm also going to reject any code that causes the library to bloat. Lastly, the library will likely be 'done' in the next few years - at which time I expect it will be mature enough that a stable final release will be possible, or someone will (re)write a superior version. I don't expect an open-source project will ever define what I accomplish in our industry. It finally occurred to me that others don't think this way when they began telling me that they don't open-source due to -

• the code isn't mature enough
• they don't want to write documentation
• they don't want their time monopolized by feature request emails

I can understand each point of view, but events have occurred in my career that have shaped my (differing) opinion.

I still remember my first open-source project: I didn't tell a soul about it until I had used it in production for over a year and was very confident that I'd addressed the majority of common use cases. It was a .net object relational mapper called NORM, and it was released in 2005. No, you haven't ever heard of it. I polished it for months, and no one cared. After that I never waited to release anything. I now believe that it's highly unlikely that whatever I create will ever gain any traction, so I might as well get it out there, fail quickly, and move on.

No one writes documentation for themselves, they write it for people who they hope will use their software - and very few people people ever gain anything from someone else using their open-source software. That simple equation makes documentation scarce; however, scarce documentation doesn't mean you can't open-source your software, it just means adoption rates will very likely be slowed.

Two years ago I open-sourced expectations with zero documentation, and documentation stayed at zero for at least a year. In that year very few people paid any attention to expectations; however, expectations does fit a sweet spot for some people, and some adoption did occur. Eventually, new adopters began to send pull requests with documentation, and their contributions inspired me to write some documentation of my own. It can be hard to get motivated about providing documentation to theoretical adopters; however, I got my code out there and adoption began, and the motivation came along with those (no longer theoretical) adopters.

If you end up lucky enough to create a project that is widely used, there's no doubt that you'll start getting swamped with email. In the beginning I expect everyone will be overjoyed with their success, and the added workload will be no big deal. However, I imagine over time it begins to feel like a second full-time job, and for what? Developer-fame doesn't get you closer to retirement any faster than watching grass-grow. However, I don't believe that should deter you from putting your work out there. Additionally, I think GitHub has changed the game with respect to moving on. If your project is on GitHub and you decide to call it quits tonight, there will probably be plenty of forks that are more than happy to take your place.

I have no qualms with walking away from projects, as I expect that if the idea is valuable, someone else will be happy to step up and take my place; furthermore, it's more likely that several people will step up and the strongest will survive - which is best for everyone. The best example I've ever seen of this behavior was Capistrano. Jamis Buck famously walked away from Cap in 2009, yet I still know plenty of people using it today without any issue. I firmly believe that if an idea is good, it'll live on even if you've decided you're ready to do something else.

It occurs to me that I might be a bad open-source citizen - releasing way too early and walking away too early as well. If that's the case, then I expect well deserved criticism, but that's just not how I see the world at this point...
© Jay Fields - www.jayfields.com

Another beautiful rant from Uncle Bob: Here’s what an application should look like. The use cases should be the highest level and most visible architectural entities. The use cases are at the center. Always! Databases and frameworks are details! You don’t have to decide upon them up front. You can push them off until later, once you’ve got all the use cases and business rules figured out, written, and tested.

8th light must be something else.

In the comments on my post about generating random numbers to test a function David Turner suggested that this was exactly the use case for which QuickCheck was intended for so I’ve been learning a bit more about that this week.

I started with a simple property to check that the brute force (bf) and divide and conquer (dc) versions of the algorithm returned the same result, assuming that there were enough values in the list to have a closest pair:

prop_closest_pairs xs = length xs >= 2 ==> dcClosest xs == (fromJust $ bfClosest xs)

I could then run that as follows:

> import QuickCheck.Test
> quickCheck(prop_closest_pairs :: [(Double, Double)] -> Property)

It failed pretty quickly because the bf and dc versions of the algorithm sometimes return the pairs in a different order.

e.g. bf may say the closest pair is (2.0, 0.0), (2.1, 1.1) while dc says it’s (2.1, 1.1), (2.0, 0.0) which will lead to the quick check property failing because those values aren’t equal:

> ((2.0, 0.0), (2.1, 1.1))  == ((2.1, 1.1), (2.0, 0.0))
False

The best way I could think of to get around this problem was to create a type to represent a pair of points and then write a custom equality operator.

I initially ended up with the following:

type Point a = (a, a)
data Pair a = P (Point a) (Point a)

instance Eq (Pair a) where
	P a b == P c d = a == c && b == d || a == d && b == c

Which didn’t actually compile:

qc_test.hs:41:58:
    No instance for (Eq a)
      arising from a use of `=='
    In the second argument of `(&&)', namely `b == c'
    In the second argument of `(||)', namely `a == d && b == c'
    In the expression: a == c && b == d || a == d && b == c

The problem is that while we’ve made Pair an instance of the Equality type class there’s no guarantee that the value contained inside it is an instance of the Equality type class which means we might not be able to compare its values.

We need to add a class constraint to make sure that the value inside P is a part of Eq:

instance (Eq a) => Eq (Pair a) where
	P a b == P c d = a == c && b == d || a == d && b == c

Now we’re saying that we want to make Pair an instance of the Equality type class but only when the value that Pair contains is already an instance of the Equality type class.

In this case we’re just storing pairs of doubles inside the Pair so it will work fine.

Now if we compare the two points from above we’ll see that they’re equal:

> P (2.0, 0.0) (2.1, 1.1)  == P (2.1, 1.1) (2.0, 0.0)
True

I had to go and change the existing code to make use of this new but it didn’t take more than 5-10 minutes to do that.

Here's a snippet from a recent comment on a oldish blog post of mine:
"However, in this post there is one thing that touches a raw nerve. The whole point about whether the person does coding in his free time. Why would you care? In fact, the point of free / spare time is to do activities you don't do at work. Today, I've an MBA and am far removed from the tech world, but I'm involved in recruiting for consulting (the industry I work in), but I'll not hire a person who does cases during his / her spare time. I'd rather hire someone who has a life and some hobbies. Such people can be much more interesting, fun to work with, and actually more versatile at solving business problems than someone who has a unidimensional personality."
Every time someone says something like this, I'm appalled. No, really, that's the only word for it.

First, I don't understand the constant assumption that if you choose to study in your spare time, you have no life. Some of the best programmers, entrepreneurs and managers I know (some are all three) run marathons, are published authors, do underwater photography and more without ever compromising on study. Truly passionate people have several passions - and their greatest passion dictates the area in which they choose to work, but never to the complete exclusion of everything else. The stereotype of the programmer living in a basement doing nothing but write code is just that - a stereotype. People who fit the stereotype are the exception, not the norm, believe me. That said, I do wish that the manager who did nothing but study cases was also a stereotype - most professional managers that I meet last read a book during their MBA (and it was the Nirma washing powder case) and haven't been exposed to a new idea since. But I digress.

I also find the 'if you study, you have no life' argument something of a cop out. It tells me that you aren't passionate about what you do for a living - if you were, studying and getting better at what you do would be something that just happened automatically. Henry Ford created the assembly line because he constantly studied manufacturing. Sam Walton created Walmart because he spent all his time studying retail. Nobody creates anything great without expending considerable effort studying the problem and trying different solutions. We aim to write great code as one of the key parts of solving our customers problems, so yes, I prefer people that are looking to become better programmers. Such people almost always hack on personal projects in their spare time; as far as I can tell, it's the quickest way to identify the best programmers.

Second is the implication that people who are passionate about what they do and express this by working on their skills outside of work hours aren't 'versatile'. I've never figured out what the connection is here. Is it that someone who does not consciously work to improve their skills must perforce be better than someone who does because they become (magically) more versatile? The answer to 'Are you an expert in your field?' isn't 'No, but I have hobbies.'

Are you saying that if you conducted an orchestra, you'd refuse to include a musician who practiced outside of the concerts they played in? Are you saying you wouldn't consult a doctor that studied the latest advancements in medicine? What's special about programmers or managers that they're exempt from others expecting them to improve their skills? As far as I'm concerned, the important thing to remember is that even if you are an expert in your field today, you won't remain one unless you're constantly introspecting and working to improve. Your career will falter, because your peers are improving while you're standing still. This isn't rocket science - everybody wants to work with the more capable person, not the less capable one that has hobbies. In my experience though, the more capable person is usually the one with the hobbies and the less capable one is usually a couch potato in his or her spare time.

Lastly, the whole notion of how people perceive learning at work as being something that must happen during working hours strikes me as being rather odd. When you were in school and college, did you do all your studying in the classroom? No - you studied in what was, technically, your spare time. So what's the deal with expecting to learn everything you need to know during your eight hours at work? Now that's what I call unidimensional - someone whose knowledge of their domain encompasses merely what they see during work hours.

To cut a long story short: To study or not to study - the choice is yours; but don't ever fool yourself into believing that passionate people that study are in any way the poorer choice for any role. That perception is a fallacy.

Update:

Here are the links to conversations around this post on Hacker News and the Software Craftsmanship list.


If you liked this post, you could subscribe to the feed Follow @ponnappa or simply comment on this post

Valve handbook. Very cool:

http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf

I had no intention of writing about this meme because I'm biased by the fact that we're building a platform to allow programmers to teach programming, but then Jeff Atwood wrote his "Please don't learn to code" post. I'm sitting at home, grumpy because I'm ill, so this was all the excuse I needed to get this off my chest.

Frankly, I don't care if Mayor Bloomberg should learn to code, mostly because I don't live in New York. For me, what's important is the fact that he will never learn to code non-trivial programs by going about it in this manner. Much of the hype on the internet misleads people into assuming that by writing a code snippet a week, they're going to become programmers. That's like assuming if you solve a Sudoku problem once a week for a year, you will become a mathematician.

Learning programming is not easy. It's easier than many other disciplines because you can learn through experimentation, but to be a good programmer, you need to make the effort to understand how computers work.

The less you understand, the less effective you are as a programmer.

You see, any non-trivial software program depends on dozens or hundreds of abstractions. For the non-programmers reading this post, an abstraction basically hides a complex mechanism or concept behind a simple interface. A real-world example of an abstraction would be the remote control of a television - you don't need to know what goes on in the circuitry of the TV to switch channels; you know that hitting that button makes it happen, and all of the underlying complexity is "abstracted away" from you, the user. This is ok, because you are not in the business of designing and building TVs.

You can certainly write many trivial programs without looking under the hood, but for bigger pieces of software, some understanding of how all the abstractions in your system work is essential. Memory management, threading, storage and scheduling are just some of the areas one needs to be familiar with before you can understand why your program behaves in a certain way. Once you get into production software you need to understand networks, packets, routing - I could go on like this for five minutes. Without understanding all of this, the behaviour of your program is a black box to you. When something goes wrong - which it will - you will have no idea why it happened. And you will not be able to fix it.

Getting the basics sorted would easily take six to twelve months of serious study. Without this, you're just messing around doing building "Hello world" programs that provide gratification to you and little else.

Long story short, there's nothing stopping anyone from becoming a kick-ass programmer, but remember, programming isn't an exception to the 10,000 hour rule.
If you liked this post, you could subscribe to the feed Follow @ponnappa or simply comment on this post

Today, I feel like a massive RANT.

Although I’d rather book myself in for a root canal than get involved in creating proposals or responding to RFPs, I do find myself in this position frequently these days and I’ve yet to develop a suitably sustainable perspective on these things to make them enjoyable.  Hell, forget enjoyable as a goal – I’d settle for a beige sort of feeling rather than the darker colours I tend to find myself wallowing in during those times.

And here’s why – proposals suck.  The act of building them… sucks.  The process they are a part of… sucks.

Why?  Well, let me give my completely objective and not-at-all bitter take on how this stuff works.

Step 1: Company A wants some stuff done.  They decide to go to market for whatever reason.  Their governance mechanisms demand some form of RFP process to ensure fairness and transparency, etc, etc (hint: it doesn’t and it isn’t, but that’s another story entirely)

Step 2: Company A taps the shoulder of some poor schmuck(s) to write the documentation describing the work to be done.  This document is usually 40% boilerplate with the rest being the gristle of the problem to be solved.  Generally the authors of these documents are domain experts so understand the problem domain quite well.  However using domain experts to explain complex problems to people who don’t share that expertise also sucks because:

• They have sublimated all the obvious questions naive people would initially ask and present the information at a level best consumed by other domain experts
• They are forced to filter their knowledge through the ultimate comprehension mangler that is… written sequential documentation
• They are often not naturally good technical writers, so I’ll leave you to your own conclusions about what impact this has
• No one ever thinks to “test” the quality of the documentation against typical end users

Step 3: Documentation is distributed to interested parties for response by a certain time.  Some RFP processes include open Q&A sessions with all the potential respondees which inevitably turn into variations of pissing contents (i.e., who can ask the questions that intimidates the other parties in terms of specificity, detail, prior knowledge, etc) or exercises in studied banality (i.e., don’t ask anything publicly which might reveal how we’re thinking about the solution).

Step 4: Respondees digest documentation and subsequently devise solution, estimates, timelines, costs, staffing models, risks, etc., etc.  Now this is where things get really interesting because I’m often part of the  ”devise solution plus estimates”  side of things and a whole new circle of Hell must be navigated to survive this phase.  The natural tensions are:

• You know that at least two stakeholders have unrealistic expectations about the accuracy of any estimates produced; Company A and your own “pursuit team”.  Often people talk about +-30% as though this is a wide enough variance at this point in the project.  All empirical studies I’m aware of around estimation accuracy suggest otherwise.  How many times have I come across a line item in the RFP document that could range anywhere between a NOOP and a 6-month piece of work in itself depending on semantics or unstated context?  How many times do literally dozens of similar statements occur in these documents.
• By definition, the accuracy of the estimate can never exceed the accuracy of the statement of the requirements.  See my previous comments about the likelihood of these requirements being accurate and/or unambiguous.
• There are three main paths you can agree to take to resolve these tensions, although none of them satisfy all the groups involved.  You can Optimise for Initial Success (i.e., winning the work) which seems to involve making the quoted numbers low and tightly bound to give the impression of thrift and confidence through an illusion of accuracy.  This process is made considerably easier if you know what the budget for the work is.  You can Optimise to Inspire Confidence by just giving an unreasonably small range for your quotes, implying we have sufficient control over all the variables required to predict with this level of accuracy (hint: we don’t).  Alternatively, you can Optimise for Prolonged Trust (between you and Company A) by responding with the numbers that initially estimation gives you and with a suitably large variance to reflect the reality of project physics.  IMO, this last type of response doesn’t lead to a lot of success (this also sucks).

Step 5: Respondees send response to Company A who now have the unfortunate task of reading, understanding, comparing and ranking n proposals.  Sometimes there is a shortlist process and you get a second bite at the cherry and refine your response.  Rarely is there any formal feedback process from Company A back to the respondees apart from the tersest of communications saying you have been successful or otherwise.

If you’re unsuccessful, I believe the required behaviour is to either justify the response by saying you didn’t want the work in the first place or rationalise the decision by saying that whoever won did so by lowballing the price with a strategy to change manage their way to profitability.

If you’re successful, then the once the project gets started, the vast majority of the assumptions you made to justify your estimates will be immediately or eventually invalidated rendering the basis of your estimates and costings null and void… this part doesn’t suck so much

Next proposal – BRING IT ON!

I have been working at Microsoft for a month now. People talk about starting here and taking it all in as "drinking from the fire hose" and at first I laughed but now I know it is the case. There is nothing as overwhelming as starting a job at Microsoft. It is also overwhelmingly enjoyable.

One thing that made me take the job was this amazing female manager who interviewed me. She was inspiring and had presence, from the second she entered the room.
I never believe that an interview is about them. Do not think that the people interviewing you are there to choose you. You have to choose them back.

Being interviewed by a woman, in a company who has a woman running their Australian arm and had that before, counted a lot towards my positive view of this  company. My friend who recommended me is a female evangelist. My male friends who work there have supported me through my career.

It is true that I didn't post on International Women's Day so I'll make today my IWD. As I sit here blogging today, knowing that so  many women helped me get to where I am.

Thank you, girls. Thank you.

Last week I completely re-worked the short presentation I share with nonprofit clients who want to get others in their teams excited about what agile practices can do for them.

If you’re a staff member or volunteer on a team, this stuff can be so very helpful. Check out the presentation: Agile – What is it and why should I care?. And feel free to ask questions. Or steal it!