I bought some YHOO shares today because I was looking for a bottom and YHOO's intraday chart for today finally looked healthy. I know I should have waited for signal confirmation on Monday but, well, went ahead with my gut instinct. I'll get some more on Monday if the signal is confirmed. If not, just hold and sweat. LOL.
Wow. Google's growth is impressive. However, Google's continuing growth represents a problem, not just Google's direct competitors, but small guys as well as advertisers. Reports I've seen predicts that online advertising market will grow at a little over 12% for search and 7% for display. If Google's growth rate continues to outpace market growth rate, will there be any room left for Web 2.0 businesses or will everyone have to just live on AdSense crumbs? If AdSense becomes the only game in town, what prevents Google from scooping up the crumbs? And what will advertisers face when Google's share of the online advertising market grow beyond 50%? Heck, Google already has 25%!
I spent an hour playing with Metasploit 3.0 beta 2 today to prepare for some server hardening chores ahead, a task I've always depended on others to do for me. Since it's for my own projects and I don't have any employees, I am it. Besides, I don't think many IT guys have Metasploit in their hardening procedure…yet.
Anyway, Metasploit looks neat. I am rather disappointed with the list of available public exploits though. Is there an 'exploit bank' I need to withdraw from? Also, it seems hideously tedious to use, check, and launch exploits. I want a GUI app that allows me to select exploits without typing, fill in a form, save as an exploit instance, optionally drag-n-drop it into an attack suite, then launch it either in parallel to ongoing attacks or into an execution queue.
Maybe msfwx is suppose to do this but I couldn't get it to run (complained about not having wxruby). Only copy of wxruby I could find was wxruby2-preview but apparently that doesn't satisfy msfwx in beta 2.
While drinking wine with my wife before bed, I described to her a new advertising business idea I came up with recently. This took me a while because I had to describe Google, AdSense, and all that before I could dive into how my idea was very different yet far more effective and desirable for everyone involved. Well, before the wine was done Stella was convinced and excited which filled me with joy and energy. What a great wife she is. She wanted me to call it StellaWare. I told her I have to sleep on that.
FYI, this was another typical night in the Valley. ;-p
I just installed IE7 and
this blog looks quite broken using that browser. Local development copy of the site looks fine though so I think it has to do with IE7 refusing to load CSS, JS, and image files from my site, probably something to do with P3P crap.
I am rather sleepy just now so I'll have to look at it in the morning. Urgh.
It's fixed now. HTML base tag was not working somehow on the remote site. More details in the comment.
Heck. My wife wants to drink some wine before bed so I have time to describe the odd behavior.
Did I misread the spec or is this an IE7 bug? What's even stranger is that, when exact same content and code is run on my local machine, IE7 had no problem.
As you might have noticed, Daily had zero optimization until now. This means every page was rendered fresh all the way from database and back, each page request needing multiple database queries to put the page together.
In this first pass, which took me 6 hours of serious huffing and puffing , I picked off naked dogs in the DAO layer which is now starting to shape up nicely using WhirlyCache, a fast lightweight java cache library. Same was done for uploaded images. While I was at it, I slipped in transaction layer to make application-level operations atomic and to prevent (well, reduce) database integrity corruption. Unlike what I said before, I opted to use Spring Framework's AOP-based transaction framework instead of using iBATIS DAO library. Using java annotation to mark transactional classes and methods, Spring was easy to use and reasonably portable. I unfortunately didn't have much time to work on reported bugs. Oh, well.
Anyhow, result of this first pass is not bad but I've got two more optimization passes planned before moving on to fleshing out the other half of Daily, over page generation level using OSCache and another at HTTP level. After the third pass, average number of database queries per page should drop well below 1.
It's fun making things fly with minimal effort.
An unfortunately common tendency among startups that depend on large account sales is making a habit out of adding new features to products on-demand like a short-order cook. The trouble usually starts with a salesman who sold too much, promising non-existent features in order to make the sale. When engineers rise up to meet the challenge, the salesman is encouraged to do the same again and again. So the engineers end up in an endless maze of trenches, fighting foes at each turn, not knowing where they are going nor where they are.
Overeagerness of sales people is not the cause of trench-fighting, complacency of engineering executives and managers is. If they looked outward as much as they did inward, they would have seen developing trends and planned ahead accordingly to deliver the needed features well ahead time.
It's not that they don't read the industry news. They do but they read industry news like they would read NY Times instead of reading them like a fisherman watching clouds forming in the horizon. It wouldn't be so bad if they listened to advisors. With each client, I go out of my way to inform them of new trends and upcoming opportunities but I doubt any of them even remember what I told them. Like a race horse, their mind is filled with what's in front of them and anything that isn't related directly to that falls on deaf ears.
In security, user education is part of the traditional formula but user training is not. The difference between the two is the level at which learning takes place. User education is about teaching users to protect themselves, not unlike sending users to nightschool. User training is about conditioning users into protecting themselves.
I think it's time to add user training to our toolbox because it's just too damn effective to ignore. And user training doesn't have to make users feel like a dog being trained. Give it a better name, like user education-by-example, and shape it as a game of sort with rewards, perhaps reduced rates or fees, for completing the obstacle course successfully.
I think YouTube purchase was a bad decision for Google as well as the industry, not because YouTube is not worth $1.6B but because there are cheaper alternatives.
If I was running Yahoo, I would quickly form a taskforce consisting of four specialized teams to attack the market from the underside: experience.
Viewer Experience – The first team, consists of mainly engineers and user experience experts, focuses on improving the quality of viewing and sharing experience beyond YouTube. A key attack vector is video quality. Using technologies like MotionDSP, viewer experience can be improve vastly. Another attack vector is video size.
Creator Experience – The second team, with similar make up as the first, focuses on improving the experience of content creators and submitters. Supporting wider selection of video source format and offering ease to use online video editing and management tools will attract content producers. Building a private P2P network will improve the uploading experience.
Advertiser Experience – The third team, consisting of advertising experts with help of engineers, focuses on making it easy for advertisers to target, track, and manage advertising campaigns.
Trendsetter Experience – The fourth team, consisting of marketing and social experts, focuses on creating new trends, to blitzkrieg for mindshare.
For example, I would create a cheap sturdy tapeless videocamera that uploads video clips directly to Yahoo video network then loan them out to selected teens across America for free. Seeding 1,000 yahoocams in each of the top US 20 cities and countrysides of all 50 states means 70,000 yahoocams are needed. At $300 a piece, the equipment cost is $21 million. Let's make that $40 million to account for extraneous costs. Compared to spending $1.6 billion, I think spending $40 million to let loose a horde of Yahoocam wielding teens roaming the whole country shooting video of whatever takes their fancy is worthwhile.
Now introduce rewards for good content. Let's call it video points or vips for short. Capturing a video of ongoing newsworthy event earns the videoshooter vips. Hotter the video is, more vips the shooter gets. Vips can be converted goods and can be used to compete for prizes of weekly or even daily contests, turning the whole thing into a game of sort.
The important thing is to think outside-the-box and to act boldly and timely. Yahoo has to launch the taskforce now to build anticipation while Google is busy integrating YouTube into its fold.