Monthly Archives: October 2005

Issues for Young People and Blogging

Issues for Young People and Blogging.

Some schools are asking students or creating policies requiring students to remove their blogs from the public internet.

The article
is about a Roman Catholic high school ordering its students to remove
personal blogs from the Internet. They are not talking about
censorship, they are trying to protect young people from
cyberpredators. I've heard similar stories from several educators who
are worried that the combination of blogging and student's general
greater willingness to provide personal information on-line can to be a
dangerous combination.

Though the article pushes the “no blogging policy” towards a free
speech debate, its really more about responsible Internet use for teens
and giving students a “safer” place to blog. As schools continue their
adoption of blogging tools as a great way to communicate in the
classroom and help kids learn to write, they also need to consider
their potential downside and find ways to mitigate that danger.

I think we all have a lot to learn here  [Scott Young's Radio Weblog]

Learning to separate value from cost

Learning to separate value from cost.

I
spent three years at the Copenhagen Business School to largely acquire
one skill: The ability to price something at its value, not cost, and
feel damn good about it. It sounds trivial, but it can be the hardest
thing. Russell Beattie gives you the guilt version:

Let me make an aside for a moment and say that I’m
always fascinated by what I call “natural business people.” These are
the folks that have absolutely no problem making money. If I buy
something for $2, I have this vague sense of guilt when I turn around
and try to sell it for $4, and even worse if I sell it for $6. It may
be worth $6 now, but I know how much I bought it for and I feel bad.
People like Bill Gates for example, don’t have this problem (remember
the story of QDOS as the prototypical example).

The inability to price at value instead of cost is what separates
nice (or niche) businesses from great businesses, what fizzles good
ideas, and what turns would-be entrepreneurs into “starved artists”.

But its also something that separates people at a moral level.
People who charge at value are often labeled as cynical or price
gaugers or downright inhuman. It creates a false split between “the
compassionate” and “the cold business people”. It's probably also one
of the prime puzzles for economists: Why is this so hard for “normal
people” to understand?

I won't attempt to pontificate on why, but I will say that
the three years was well worth it. Not only as a way of conducting
business, but as a way of developing projects and products (even living
life, to be grand!). In some ways, I think its my most important skill
and asset for programming. The ability to discern value and make calls
based on it: Worth it?

This is naturally what attracts me to simple problems. What's the
least amount of work I can do that ends up having big value? Before
I've cleared all the simple problems of high value, it's just not for
me to engage in solving hard problems. Too much risk, not enough ratio.

(Oh, and just to satisfy Russell: If you're not using Ruby on
Rails for your start-up, it's going to fail. No buts, no discussion.
Fail. Hear?)
  [Loud Thinking]

Mike Arrington's new stream

Mike Arrington's new stream.

Most of you know Mike as the editor of TechCrunch,
a phenomenal new weblog that tells the story of new web services,
written from the heart of SiliconValley. I met him for the first time
in a meeting in NY, in May, when we got together to talk about the sale
of weblogs.com.

Today Mike starts a new blog, called CrunchNotes
by telling the story of how TechCrunch got started. He credits me with
being an inspiration, and if it's really true, he's taken it so far and
done it so well, all the credit belongs to him. Really.

What
he says is so true. Too many software developers wander into the market
without knowing what's been tried before, what worked, what didn't.
Often the users know more about the history of the category than the
designer of the software. What Mike does, by writing up every product
and service that he sees, is the beginning of a process that we must
develop; but is itself a revisit of something that used to be done
thoroughly and systematically, but because of the quick pace of boom
and bust in the tech business, is an art that now needs to be
reinvented, a bootup that's actually a reboot.

Mike is a
lawyer. Laws have precedents. When it was thought that Harriet Miers
believed in a constitutional right to privacy, many inferred that she
was a choice advocate. One position implies another because legal
decisions are based on previous decisions. Sometimes a higher court
changes direction and overturns a precedent, this is necessary because
the context changes over time. It's true in technology too. In 1985 we
designed software to run in 640K; today my machine had more than 500
times that amount of memory, but in order to make it run adequately, I
had to double it. Laws that made sense in 1985 clearly need another
look in 2005.

In software, I call this system of precedents design by prior art.
To really make it work, we need to go back and scour the past for lost
art. It's not enough to just chronicle what's coming online now
(although I'm glad we're doing that). Maybe the next step is for Mike
and I to visit Michael Miller, who, as editor-in-chief of InfoWorld and
then PC Mag (where he still is, I believe) put in place a system for
looking at software over time. That was a system of prior art in
software.

There's another reason it's a good idea to
study the past in software — anything that was designed or implemented
before software patents forms a prior art defense against the patent
system of the 21st century. Mike, being both a lawyer and a student of
technology, is in a great position to lead us here.

In any
case, congratulations to my friend Mike, for doing this work so well.
It's great when someone so talented and motivated finds something that
suits him so well. How lucky for him, but then we're lucky too, because
we get the full benefit of his brilliance, without having to do the
work! “;->  [Scripting News]

The top 5 red flags of software development

The top 5 red flags of software development.

  1. “Wouldn’t it be easy to…” (the hidden cost of change)
  2. “This shouldn’t take long” (artificial time frame)
  3. “Can you make this small change real quick?” (“small” and “quick”)
  4. “Before you finish X, could you do Y?” (the mental costs of interruption)
  5. “Let’s push this today” (artificial scope)

[Signal vs. Noise]

Lind on “processing” failed states

Lind on “processing” failed states

Lind.
Another reason the WMD lie matters is that the real reason the
administration invaded Iraq, “to redesign the Middle East,” reveals
(officially) a truly breathtaking hubris, coupled to a monumental
ignorance of the region in question. Redesign the Middle East? What do
the Bushies think it is, a Chevrolet?

At it happens, the war in Iraq is redesigning the Middle East, but
not exactly in a planned fashion. Just as the calling of the Estates
General in 1789 opened the door to the French Revolution, so the
American destruction of the Iraqi state has opened the door to a
broader collapse of the state system in that region, an outcome the
administration is now pushing in Syria as well. Osama, sitting in his
cave, no doubt continues to thank Allah for President George W. Bush.
  [John Robb's Weblog]

Swan song?

Swan song?.

My first reaction to Delta to Eliminate Discount Carrier Song
was, “of course it failed.” It failed because they didn't burn their
bridges, didn't really commit, didn't do anything but a pale imitation
of Jet Blue.

But then I realized that Song wasn't a failure on at least one
level… it allowed a stodgy brown company to move fairly quickly and
to discover the power of story telling. Everything from the organic
food to the paint job was about telling passengers a different story.
Song had trouble keeping that promise, but at least they tried.

So maybe Delta learned a lesson about flexibility and speed and risk. Failure is rarely fatal.  [Seth's Blog]

Optimizing Rails Resource Usage

Optimizing Rails Resource Usage.

Hi,
my name is Julik and I'm one of the new guest writers on the
TextDrive weblog. Jason has given me the privilege to talk a little
about performance-tuning Rails applications for deployment on TextDrive
or anywhere.

I've been doing Rails development since
April 2005 and have deployed 3 applications already, all for client
use. Since then I have encountered quite some problems which are not
covered well on the Rails wiki, partly because they pertain to running
Rails on shared hosting accounts.

Rails is nuclear
stuff, it allows you to do wonders in minutes but you have to be
careful with it. The amount of magic contained in Rails imposes quite
an overhead — that you, as a developer, are obliged
to manage. These things not only make your application faster, scalable
and tolerant, but also bearable for people living on the same web and
application servers. Failures to do this in a shared heteregenous
environment certifably leads to memory leaks and hard crashes. These
tips are good standard procedures for a Rails application at any level
(even if you are on a dedicated cluster setup).

So here it goes, a list of 10 things I recommend to do to streamline your application and make it more bearable for others.

In short,

  1. Minimize the amount of FCGI listeners
  2. Use caching
  3. NEVER run “development” on FastCGI for more than 1-2 hours
  4. Observe your memory consumption
  5. Rotate your logs
  6. Write and run unit tests
  7. Check for memory leaks when you are developing
  8. Be careful with iterations
  9. Watch the Rails TRAC for bug reports
  10. Be vigilant when restarting your server

And in detail . . .  [TextDrive Weblog]