Link > 5 Reasons Not to Share Your Roadmap
There is always a strong temptation to share the product roadmap. It is rarely a good idea because of the flexibility you give up.
-
-
“Working without a plan may seem scary. But blindly following a plan that has no relationship with reality is even scarier.”
— Jason Fried
-
Link > In Praise of Quitting Your Job
Great stuff:
“As a creative person, you’ve been given the ability to build things from nothing by way of hard work over long periods of time. Creation is a deeply personal and rewarding activity, which means that your Work should also be deeply personal and rewarding. If it’s not, then something is amiss.”
“Ownership not as a percentage of equity, but as a measure of your ability to change things for the better. … States of approval and decisions-by-committee and constant compromises are third-party interruptions of an internal dialog that needs to come to its own conclusions.”
“Your muse can only be treated as the secretary of a subcommittee for so long before she decides to pack up and look for employment elsewhere. If you aren’t able to own the product and be creative, then you aren’t able to do your work, and if you’re not doing your work then you’re negating a very real part of your personality, which is no good for anyone.”
-
Enlarge an ext3 Amazon EBS volume
Have an EBS volume that’s filling up? Follow these steps to enlarge it:
At the EC2 Web Console
- Unmount the volume.
- Take a snapshot of the volume.
- Create a new volume from the snapshot (at the new, bigger size)
- Detach the old volume
- Attach the new, bigger volume.
In a shell of the instance
- fdisk /dev/sdx (then type: d, n, p, 1, <enter>, <enter>, w)
- ec2fsck -f /dev/sdx
- resize2fs -p /dev/sdx
- fsck -f -y dev/sdx
- mount /vol
That’s all! Original source and details at:
http://www.capsunlock.net/2009/06/enlarge-amazon-ebs-volume.html
and
http://developer.amazonwebservices.com/connect/thread.jspa?messageID=112259
-
Link > Paul Graham's 6 Principles
Find (1) simple solutions to (2) overlooked problems that (3) actually need to be solved and (4) deliver them as informally as possible, (5) starting with a crude version 1, then (6) iterating rapidly.
- Simple solution (spot on Paul!)
- Overlooked problem (I would say, “not adequately solved for some group”)
- Needs to be solved (I would say, “an important problem”)
- Deliver informally (this can’t be improved upon)
- Starting with a crude version 1 (You shouldn’t release anything crude. I’d say, “starting with the minimally viable version 1”)
- Iterating rapidly (this can’t be improved upon)
-
Link > Why Free Plans Don't Work
“The only thing that seemed to be consistent about my growth was that my revenue was relatively flat while my user base kept growing.
If I stayed on this path, I’d soon have thousands of free users to support.”
-
“Defending yourself in advance against the possible ramifications of success has strong diminishing returns. It is more important to try something new, and work on the problems as they arise, than to figure out a way to do something new without any problems.”
— Clay Shirky in Cognitive Surplus
-
Zipper
A zipper is a data structure that provides constant time access for some important class of operations, namely access to the current, next, and previous elements, and insert and delete at the current element.
For those not familiar, the difference between a data structure that provides O(log n) or O(n) for an operation, and one that provides constant time, is that the former take longer and longer as the number of elements in the data structure grow, while the latter takes a fixed amount of time, even as the data in the data structure grows.
A zipper uses two lists:
{ [ previous | list of previous items in backwards order ], [ current | list of next items in forward order ] }
So a zipper of the alphabet, that is currently at the letter L looks like:
{ [ K | J,I,H,G,F,E,D,C,B,A ], [ L | M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z ] }
To traverse to the next letter, M, we simply take the head (L) off the second list and append it to the first. That happens in constant time of course.
{ [ L | K,J,I,H,G,F,E,D,C,B,A ], [ M | N,O,P,Q,R,S,T,U,V,W,X,Y,Z ] }
To traverse to the previous letter, we simply take the head (L) off the first list and append it to the second. It’s the same operation, so of course it happens in constant time too.
{ [ K | J,I,H,G,F,E,D,C,B,A ], [ L | M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z ] }
Now let us suppose the IAA (International Alphabet Association) decreed that there should be a new letter ∀ (pronounced vlork) that comes between K and L. We simply insert vlork as the head of the 2nd list. A constant time operation.
{ [ K | J,I,H,G,F,E,D,C,B,A ], [ ∀ | L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z ] }
And when the IAA comes to their senses after the inevitable public outcry, we delete vlork by removing it from the head of the 2nd list. You guessed it, still in constant time.
{ [ K | J,I,H,G,F,E,D,C,B,A ], [ L | M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z ] }
Our example alphabet list has just 26 items. But it could have 26 million items and the time it takes to get the current item, traverse to the next item, traverse to the previous item, insert at the current place, or delete at the current place is constant.
A zipper may not seem like much for languages with pointers or dynamic object references, since it has the same access time characteristics as a doubly-linked list. But for functional languages like Erlang or Haskell, with single assignment and no pointers (very important characteristics for robust concurrency), the zipper is an important data structure.
Thus far, I’ve only talked about zippers and lists. More later on zippers and trees.
References:
-
Link > Build What Had Not Been Possible
“Over the course of history new building blocks become available, which allow us to build companies that weren’t possible before. The crucial part to changing the world as an entrepreneur is to use these new building blocks to build what had previously not been possible.”
