November 20th, 2007 by Moti Karmona | מוטי קרמונה · No Comments
Due to the increasing demand (~300% in the last week) for I18N support in my blog, I decided to take action.
My pragmatic ROIDB (ROI Driven Blogging) approach brought the Google-Translate-Widget to the left pane of my blog with ~20 minute copy-paste work (this post included).
I almost tripled my blog exposure from 350 Million (English) Internet users to 1 Billion* internet users (85% of the world internet users) and I also hit the pareto princple (80/20) jackpot on the way :-)
But… I can’t really use the “I don’t have enough traffic due to I18N readiness” excuse anymore and the 3 people that allegedly asked for I18N support only wanted to “help” with my desist Nigerian cousin will arrangement so I am not so sure it was worth it after all…
Feel free to get a taste of this I18N perfection using my new left-pane state-of-the-art translator widget and with my personal favorite Spanish Blog Flavor
* 365 English + 184 Chinese (!!!) + 101 Spanish + 86 Japanese + 59 French + 58 German + 47 Portuguese + 34 Korean + 31 Italian + 28 Arabic = ~1 Billion Internet users (Based on internetworldstats.com statistics)
Tags: Google · Internet · Pareto
November 18th, 2007 by Moti Karmona | מוטי קרמונה · No Comments
Delver is looking for great people to join our A-Team (Excuse my “eighties”)
Please email us (jobs @ delver. com) with resumes if you are ready for the delver challenge.
November 14th, 2007 by Moti Karmona | מוטי קרמונה · 1 Comment
Wikipedia is one of the best online tools (and my personal favorite) with over 1.8 million articles about everything you always wanted to know but was afraid to ask…
but Wikipedia is also the biggest online bureaucracy with very impressive set of regulations, policies and guidelines which will make Max Weber turn in his grave twice; This bureaucracy is governed by unfriendly-easy-trigger-not-too-smart-enforcement intendant bots and WikiLawyerians which make the average Pragmatic Wikipedia editor turn around and leave Wikipedia to the bots (dogs)
I think I am on to a new web conspiracy: “Google is a Wikipedia subsidiary” – You surely experience the trend yourself e.g.
* Try to Google: ‘World Wide Web‘, ‘England‘, ‘Mars‘ and even ‘God‘
* Wikipedia climbed to the 8th traffic rank (Based on Alexa lateset traffic details)
I really liked this Wikipedia rule since it reminded me of my early childhood ;-)
“The three-revert rule (often referred to as 3RR) is a policy that applies to all Wikipedians, and is intended to prevent edit warring – An editor must not perform more than three reverts, in whole or in part, on a single page within a 24-hour period. A revert means undoing the actions of another editor, whether involving the same or different material each time. Any editor who breaches the rule may be blocked from editing for up to 24 hours in the first instance, and longer for repeated or aggravated violations.”
I am thinking (day dreaming) about writing my own little vicious Wikipedia bot someday – I shall call him… Mini-Me!
Tags: Conspiracy · Google · Internet
November 10th, 2007 by Moti Karmona | מוטי קרמונה · No Comments
During the weekend I have finished the book “Born on a Blue Day” by Daniel Tammet
This unique first-person story opens a window into the mind of a 27-year-old autistic savant with Asperger’s syndrome.
Daniel is capable of incredible feats of memorization and mental calculation. Besides being able to effortlessly multiply and divide huge sums in his head with the speed and accuracy of a computer; Daniel, learned Icelandic in a single week and recited the number Pi up to the 22,514 digit, breaking the European record (3-14-2004 Pi Day)
Daniel also experiences synesthesia which is an unusual neurological syndrome that enables him to experience numbers and words as shapes, colors, textures and motions.
“I was born on January 31, 1979 — a Wednesday. I know it was a Wednesday, because the date is blue in my mind and Wednesdays are always blue, like the number 9 or the sound of loud voices arguing. I like my birth date; because of the way I’m able to visualize most of the numbers in it as smooth and round shapes, similar to pebbles on a beach. That’s because they are prime numbers: 31, 19, 197, 97, 79 and 1979 are all divisible only by themselves and 1. I can recognize every prime up to 9,973 by their “pebble-like” quality. It’s just the way my brain works.”
“The number 11 is friendly and 5 is loud, whereas 4 is both shy and quiet — it’s my favorite number, perhaps because it reminds me of myself. Some are big — 23, 667, 1,179 — while others are small: 6, 13, 581. Some are beautiful, like 333, and some are ugly, like 289″
“One of the most common questions I was asked … was: Why learn a number like pi to so many decimal places? The answer I gave then as I do now is that pi is for me an extremely beautiful and utterly unique thing. Like The Mona Lisa or a Mozart symphony, pi is its own reason for loving it.“
Daniel stated in his book that it wasn’t easy to find enough (digits) Pi in the web, so inspired from his book, I have created an online “backup”* for the first 10 million digits of Pi @ http://pi.karmona.com
* During August 1995, Dr.Takahashi and Dr. Y.Kanada have managed to calculate pi up to 4,294,960,000 decimal digits (current world record) using a supercomputer at the University of Tokyo – The University ftp server was Daniel’s (& my backup) source…
Tags: Internet · People
November 8th, 2007 by Moti Karmona | מוטי קרמונה · 1 Comment
My rough estimation is that the number of software project managers in the world is smaller in (at least) one scale from the conceived time-estimation techniques and this post is my humble four-cents contribution on how to do pragmatic time estimation for software projects (just finished one in Delver).
- Start with the mother of all lists to store your Product Manager wish list– We use eScrum Product-Backlog to store our work-items
- Prioritized them – We use 0-Yesterday; 1-Must; 2-Important; 3-Nice-to-Have and 4-“Forget-About-It”… ;-)
- Get relative estimations on all items
- Granularity is the bronze-bullet for time estimations – Strive to the finest grained possible in reasonable time-frame e.g. We usually aim for 2-5 days granularity in 2-3 days of time-boxed-estimation-period since the finest granularity in planning without reasonable time-box might take twice the time of doing the planned work (a.k.a. The Estimation Paradox)
- Experience can turn your bronze bullet into silver one (ye ye, a silver one) – Relative estimation is calculated relatively upon a common scale of known work items from the team history e.g. We use Scrum “Story Points” and constantly measure the team velocity for time estimation adjustments
- Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 etc.) can be used to “embed” the complexity and risk of rough (with insufficient drilldown) estimations e.g. if your estimation granularity for specific task reach ~40 days then your pragmatic estimation should be around 55 days (= the closest Fibonacci sequence) since it is reasonable to believe your (insufficient) granularity conceals risk, complexity and unknowns issues which requires Fibonacci-like-“buffering”
- Strive to synchronize your time estimation techniques into very simple one – different time estimation conventions in the same development team is the 2nd reason for time delays. (I will give 0.95$ grant if you can guess what the 1st reason)
- I know I am different but personally, I do prefer to have “pragmatic hours” vs. the normal Agile “ideal hours” and to start the project when 1 “Story Point” = 1 “Pragmatic Day” so long everyone understand this will change as soon as you start the project and then you need to return to velocity tracking to calculate the end
- Don’t be naïve (a.k.a. “Ideal Days”) with two known flavors:
- Optimistic time estimations, assuming 24*7 of concentrated programming ability with no outside interference (a.k.a. no such thing)
- “Stupid” hand-waiving time estimations a.k.a. It is only 10 min to code this (but ~5 days to Integrate, Review, Design, Test, Schema and DAL changes, I18N support, Styling etc.)
- Get the rough project estimation = Sum of all product backlog story points / 22 (work days in month) / Number of relevant people
- Usually this calculation will show you don’t have enough time for the project (even without project dependencies buffer which can be added later)
- Start the “Tradeoff Game” – Try to cut items (content) based on the relative ROI
- Revalidate your priorities since they will be the main tool (beside dependencies) for creating the project work plan.
As I see it, estimating software projects in a realistic time-frame is a statistic prediction of chaotic, time-delay-series of events and will never be straightforward nor easy so you can only do your best in the estimation and then track the project as it goes and make the needed adaptation on the way upon crystal clear project priorities.
Tags: Agile · Delver · Development · Management · Planning · Project Management · Scrum · Software Management