Comments for Adam Jordens@littlesquare:~/ http://littlesquare.com Just a little square in a sea of blogs. Sun, 27 Jun 2010 19:34:45 +0000 hourly 1 http://wordpress.org/?v=3.0 Comment on Sanofi Aventis developing iPad Applications? by TimmyD http://littlesquare.com/2010/06/sanofi-aventis-developing-ipad-applications/comment-page-1/#comment-254147 TimmyD Sun, 27 Jun 2010 19:34:45 +0000 http://www.littlesquare.com/?p=390#comment-254147 OK dude, you've actually got me interested in it. Nice. OK dude, you’ve actually got me interested in it. Nice.

]]> Comment on A tale of two computers : the iPad vs. Netbook by TimmyD http://littlesquare.com/2010/05/a-tale-of-two-computers-the-ipad-vs-netbook/comment-page-1/#comment-251094 TimmyD Sun, 16 May 2010 20:51:15 +0000 http://littlesquare.com/2010/05/16/a-tale-of-two-computers-the-ipad-vs-netbook/#comment-251094 Nice review, and entertaining, too (permanently popped collar? Isn't that you?!) Regarding so-called 'netbooks', I just don't think I could fork over even 400- for something produced by Acer (or the likes). The quality just isn't there IMHO. Now the argument for a couch/bed-worthy iPad is slick - 3rd degree nut-burns indeed! Nice review, and entertaining, too (permanently popped collar? Isn’t that you?!)

Regarding so-called ‘netbooks’, I just don’t think I could fork over even 400- for something produced by Acer (or the likes). The quality just isn’t there IMHO.

Now the argument for a couch/bed-worthy iPad is slick – 3rd degree nut-burns indeed!

]]> Comment on My Amazon.com Interview Experience by Soumya Paul http://littlesquare.com/2006/04/my-amazoncom-interview-experience/comment-page-1/#comment-248786 Soumya Paul Fri, 02 Apr 2010 21:13:11 +0000 http://www.jordens.org/?p=167#comment-248786 How do I prepare for an amazon on-site interview How do I prepare for an amazon on-site interview

]]> Comment on Having fun and writing good software by TimmyD http://littlesquare.com/2010/03/having-fun-and-writing-good-software/comment-page-1/#comment-247619 TimmyD Wed, 03 Mar 2010 10:14:53 +0000 http://littlesquare.com/2010/03/01/having-fun-and-writing-good-software/#comment-247619 Great summary. Things are a bit different in my current team. There is no Crucible reviews (but we will start a trial run in April), and we use the cards on a whiteboard method. I like it. The reason that the cards method works here is that there isn't a 1-1 mapping between the task cards and JIRA issues, like what you have in your team. This is sometimes frustrating for me, but I embrace the lack of process overhead. The lack of meetings is critical to productivity for the team. Now that I'm no longer a team lead, I actually get a bunch of coding done - it's refreshing. And I see that the whole team is pretty much at their keyboards every day. We run 3-week sprints, but the feature-freeze is the end of the 2nd week. The final week is used for fixing bugs created in the new features, or, if none are found, for fixing bugs from the backlog. There is one full day of planning and retrospective meetings every sprint (spread out over a two-day period). One of the meetings that I most enjoy is the "Code Retrospective" meeting. This is strictly for developers. We have the opportunity to present code that we worked on, wrestled with, created, modified, etc. It's been an incredibly useful meeting to share knowledge among the team. In addition, we work strictly in the trunk. There are no 'project' branches. If a feature is of significant size, then it gets worked on in small chunks. So long as it is stable by the end of the sprint - not necessarily complete - just stable. I agree with you about Atlassian. We have just upgraded to Jira 4, Confluence 3.1 and got FishEye full version. Will trial Crucible soon. Continuous integration is done with Hudson, but how long will that last once we have the rest of the Atlassian suite? Great summary.

Things are a bit different in my current team. There is no Crucible reviews (but we will start a trial run in April), and we use the cards on a whiteboard method. I like it.

The reason that the cards method works here is that there isn’t a 1-1 mapping between the task cards and JIRA issues, like what you have in your team. This is sometimes frustrating for me, but I embrace the lack of process overhead.

The lack of meetings is critical to productivity for the team. Now that I’m no longer a team lead, I actually get a bunch of coding done – it’s refreshing. And I see that the whole team is pretty much at their keyboards every day.

We run 3-week sprints, but the feature-freeze is the end of the 2nd week. The final week is used for fixing bugs created in the new features, or, if none are found, for fixing bugs from the backlog.

There is one full day of planning and retrospective meetings every sprint (spread out over a two-day period).

One of the meetings that I most enjoy is the “Code Retrospective” meeting. This is strictly for developers. We have the opportunity to present code that we worked on, wrestled with, created, modified, etc. It’s been an incredibly useful meeting to share knowledge among the team.

In addition, we work strictly in the trunk. There are no ‘project’ branches. If a feature is of significant size, then it gets worked on in small chunks. So long as it is stable by the end of the sprint – not necessarily complete – just stable.

I agree with you about Atlassian. We have just upgraded to Jira 4, Confluence 3.1 and got FishEye full version. Will trial Crucible soon. Continuous integration is done with Hudson, but how long will that last once we have the rest of the Atlassian suite?

]]> Comment on Upgraded to Leopard : Making use of /etc/paths.d and path_helper by Timo Meinen http://littlesquare.com/2008/01/upgraded-to-leopard-making-use-of-etcpathsd-and-path_helper/comment-page-1/#comment-245931 Timo Meinen Tue, 19 Jan 2010 08:14:32 +0000 http://littlesquare.com/2008/01/24/upgraded-to-leopard-making-use-of-etcpathsd-and-path_helper/#comment-245931 You can just erase the default PATH entry before path_helper is called like this: if [ -x /usr/libexec/path_helper ]; then PATH="" eval `/usr/libexec/path_helper -s` fi Then you have full control in /etc/paths and /etc/paths.d. Do this in /etc/profile /etc/csh.login /etc/zprofile You can just erase the default PATH entry before path_helper is called like this:

if [ -x /usr/libexec/path_helper ]; then
PATH=”"
eval `/usr/libexec/path_helper -s`
fi

Then you have full control in /etc/paths and /etc/paths.d. Do this in

/etc/profile
/etc/csh.login
/etc/zprofile

]]> Comment on Upgraded to Leopard : Making use of /etc/paths.d and path_helper by John Bledsoe http://littlesquare.com/2008/01/upgraded-to-leopard-making-use-of-etcpathsd-and-path_helper/comment-page-1/#comment-245317 John Bledsoe Thu, 07 Jan 2010 04:52:12 +0000 http://littlesquare.com/2008/01/24/upgraded-to-leopard-making-use-of-etcpathsd-and-path_helper/#comment-245317 In Snow Leopard, moving "/usr/local/bin" to the top in "/etc/paths" now works without modifying "/etc/profile". In Snow Leopard, moving “/usr/local/bin” to the top in “/etc/paths” now works without modifying “/etc/profile”.

]]> Comment on When Good is Enough (and when it isn’t) by ajordens http://littlesquare.com/2009/12/when-good-is-enough-and-when-it-isnt/comment-page-1/#comment-244700 ajordens Thu, 24 Dec 2009 18:27:30 +0000 http://littlesquare.com/2009/12/01/when-good-is-enough-and-when-it-isnt/#comment-244700 Depends on your definition of 'well executed'. And who's to say that the 100% complete plan would be shippable either. Obviously one gets to 80% quicker than 100% and should be in a position to fail faster if it turns out it's a mistake. However, if you're executing effectively, you should know well in advance of a ship date if you're on the mark. Basically, what I'm suggesting is that the focus should be on getting less features out but with more frequency (but it's a difficult thing to do with enterprise software). As for a developer's role, IMO it should be to produce 'usable' code, adding value for both the customer and business. Usable code is shippable, not all shippable code is usable. Depends on your definition of ‘well executed’. And who’s to say that the 100% complete plan would be shippable either.

Obviously one gets to 80% quicker than 100% and should be in a position to fail faster if it turns out it’s a mistake. However, if you’re executing effectively, you should know well in advance of a ship date if you’re on the mark.

Basically, what I’m suggesting is that the focus should be on getting less features out but with more frequency (but it’s a difficult thing to do with enterprise software).

As for a developer’s role, IMO it should be to produce ‘usable’ code, adding value for both the customer and business. Usable code is shippable, not all shippable code is usable.

]]> Comment on Terracotta vs. JBoss – The Numbers by cs http://littlesquare.com/2007/05/terracotta-vs-jboss-the-numbers/comment-page-1/#comment-244496 cs Mon, 21 Dec 2009 11:59:03 +0000 http://www.jordens.org/2007/05/05/terracotta-vs-jboss-the-numbers/#comment-244496 Be VERY careful with terracotta. In our experience of using it: - it's poorly supported (the responses on the forum are misty and often confusing, you will often get no direct (or even any) answer to your direct question) - it's unstable sometimes (http://forums.terracotta.org/forums/posts/list/2801.page) - if you need real-world scalability you have to BUY FX edition (again http://forums.terracotta.org/forums/posts/list/2801.page) No argue, the framework is powerful. But be ready to PAY for it. Be VERY careful with terracotta.
In our experience of using it:
– it’s poorly supported (the responses on the forum are misty and often confusing, you will often get no direct (or even any) answer to your direct question)
– it’s unstable sometimes (http://forums.terracotta.org/forums/posts/list/2801.page)
– if you need real-world scalability you have to BUY FX edition (again http://forums.terracotta.org/forums/posts/list/2801.page)

No argue, the framework is powerful. But be ready to PAY for it.

]]> Comment on Good-bye Exchange, it was nice knowing you (I hope) by bursamy http://littlesquare.com/2009/05/good-bye-exchange-it-was-nice-knowing-you-i-hope/comment-page-1/#comment-243689 bursamy Fri, 11 Dec 2009 12:02:43 +0000 http://littlesquare.com/2009/05/21/good-bye-exchange-it-was-nice-knowing-you-i-hope/#comment-243689 Is Windows 7 much much superior than Vista, should i upgrade immediately? Is Windows 7 much much superior than Vista, should i upgrade immediately?

]]> Comment on When Good is Enough (and when it isn’t) by Tim http://littlesquare.com/2009/12/when-good-is-enough-and-when-it-isnt/comment-page-1/#comment-243255 Tim Wed, 02 Dec 2009 08:09:09 +0000 http://littlesquare.com/2009/12/01/when-good-is-enough-and-when-it-isnt/#comment-243255 I think your statement: "a well executed plan only 80% complete, is worth leaps and bounds more than a flawed plan 100% complete" is strange. The risk with something only 80% complete is if it's the *wrong* 80%, and now we cannot ship. I believe a software developer's role is to "produce shippable code". I think that you agree with me. :) I do *love* the mantra of "Get it in, because you need the feedback". It always amazes me how much discussion and debate and swirl can happen over vapour-ware. Just build a simple mock up that people can look at and interact with. Then you will find out what really matters. I think your statement: “a well executed plan only 80% complete, is worth leaps and bounds more than a flawed plan 100% complete” is strange.

The risk with something only 80% complete is if it’s the *wrong* 80%, and now we cannot ship.

I believe a software developer’s role is to “produce shippable code”. I think that you agree with me. :)

I do *love* the mantra of “Get it in, because you need the feedback”. It always amazes me how much discussion and debate and swirl can happen over vapour-ware. Just build a simple mock up that people can look at and interact with. Then you will find out what really matters.

]]>