Email ile gelen bir yazıyı paylaşmak istiyorum.
Üzeyir Garih ten bir yazı, sanırım kitaplarından birisinden, hangisi olduğunu gönderen olursa yayınlamak isterim. Benim okuduğumda değildi.
Güzel bir kişisel gelişim yazısı.
1951 yılının Temmuz ayında 17 arkadaşımla birlikte İTÜ Makine
Fakültesi'nden başarılı bir öğrenci olarak mezun oldum.O gün hayatımın en mutlu günlerinden biriydi. Sınavlara hazırlanmaktan para getirebilecek işleri altı aydır ihmal etmiştim. Parasızdım. Ancak Yüksek Mühendis diplomasını kazanmış olmaktan dolayı mutluydum.O sabah motor dersi hocalarımız, ikisi de asistan olarak çalışan Prof. Necmettin Erbakan ve Prof. Hakkı Öz'ün karşısında başarılı bir motor sınavı ve mezuniyete hak kazanmıştım. Bu olayı kutlamak için bir arkadaşımla Moda'da yazın ilk deniz banyosunu yapmayı ve kendimize bir ziyafet çekmeyi kararlaştırdık. Mayolarımızı yanımıza almıştık.Arkadaşı m Moda'ya gitmeden önce yeni inşa edilen Levent Mahallesi'nde otobüsle bir tur atıp Türkiye'de o gün için yepyeni bir olay olan bir uydu villa kenti gezip görmeyi teklif etti. Merakla kabul ettim. Levent,alt yapısı tamamlanmış villaları toparlar görünümdeydi.Yolları o zamanlar pek ender rastlanan bir şekilde tamamen asfalttı. Otobüsten inip merakla yürürken bir villanın kapısının önünde villa sahibi ile bir amelenin yüksek sesle tartışmalarına tanık olduk. Merakla yaklaştık.
Bizi gören villa sahibi sanki içini dökmek ister gibi bize dönerek:
-Burada temizlenecek bir su deposu var. Tam yevmiye veriyorum yapmıyor.Ne ister bilmem ki, diyordu.
Amele ise;
-Bu iş geceye kadar sürer, kurtarmaz! Kahveye gidip yarına kadar uygun iş ayarlarım, diyordu.
Arkadaşımla aynı şeyi düşünmüş gibi bakıştık. İkimiz de parasız sayılırdık. Amele yevmiyesi ise 6 lira idi. Bizim o günkü ihtiyacımızın hemen hemen iki misli.
Villa sahibine bu işi yapmaya hazır olduğumuzu söyleyince,
amele homurdanarak
-Canınız çıksın da anlayın halimizi, diyerek uzaklaştı.
Mayoları mızı giydik. Deponun pırıl pırıl temizlenmesi bir saat sürmemişti. O sıcak yaz gününde bahçede hortumla duşlandık. Havlu fabrikası sahibi olduğunu sonradan öğrendiğimiz ev sahibi,kim olduğumuzu anladıktan sonra altışar lira ile birer havlu hediye ederek ve birer gazoz ikram ederek uğurladı.Bu işte kanımca tek kaybeden 'Kurtarmaz!' diyen amele olsa gerek. İş mi çoktu? Insanlar mi tembeldi? Neyi 'kurtarmaz' idi? Bu güne kadar da anlamis degilim
Uzeyir GARİH
Dr. Üzeyir Garih eserlerine bu linkten ulaşabilirsiniz.
http://www.uzeyirgarih.alarko.com.tr/baskankitap1/BBatkitap.htm
Thursday, November 27, 2008
Tuesday, November 25, 2008
Devrim Otomobil öyküsü (Devrim Arabaları)
Yıl 1961. Ordunun binek otomobil gereksinimini karşılamak için, cumhurbaşkanı Cemal Gürsel otomobil üretilmesini ister. 16 Haziran 1961’de Devlet Demiryolları Fabrikaları ve Türk mühendislerine görev düşer. Tamamen Türk mühendislerince, Türk yapımı bir otomobil yapılmasına karar verilir. Yapılan üst düzey toplantılarda alınan kararla, dört buçuk ay gibi bir zamanda Devrim Otomobil’in tamamlanması gerekmektedir. Otomobil 29 Ekim 1961 Cumhuriyet Bayramı’na yetişmelidir. Ödenek, bir milyon dört yüz bin Türk Lirası’dır.
İnanılmaz şey gerçekleştirilir, Türk mühendisleri gece gündüz, büyük bir özveri ve azimle Devrim Otomobil’i yetiştirirler. Eski bir altı silindirli Chevrolet motorunun iki silindiri kesilerek kalıp yapılmış, motor gövde ve başlığı Sivas Demiryolları Fabrikası’nda dökülmüştür. Ankara Fabrikası’nda işlenmiştir. Segman, piston Eskişehir’de yapılıp, Ankara Fabrikası’nda monte edilmiştir. Gücü kırk BG'dür. Şanzımanlar tamamen yerli olarak Ankara Fabrikası'nda yapılmıştır. Orijinal jantlarında ve kaputta “Devrim” yazmaktadır. Ön panel kadranları Türkçedir; yani “yağ”, “benzin”, “hararet”.
Devrim Otomobil’in son eksiklikleri Eskişehir-Ankara arasında trende giderilir. İki otomobil vardır trende; cilalanır, tehlikeye karşılık benzin koyulmaz. Cumhuriyet Bayramı törenine cumhurbaşkanı bu otomobille gitmek istemektedir. Törene cumhurbaşkanını götürecek otomobile zamanında benzin koyulması unutulur. Yüz metre sonra otomobil durur… Direksiyondaki mühendisin benzin bitti demesi üzerine cumhurbaşkanı; “Batı kafasıyla otomobil yaptınız, Doğu kafasıyla benzin koymayı unuttunuz,” der. İkinci otomobile benzin koyularak yola devam edilir ancak; “Devrim Otomobil” basının diline düşmüştür artık…
Ertesi gün bütün basın, arkasına yerli ve yabancı işbirlikçi güçleri alarak "Devrim"e saldırırlar. Türk mühendisleri ve Türk otomobili yerden yere vurulur. Hiçbir yerde, hiçbir otomobil bu kadar karalanmamıştır. Kimileri modeli çalıntı der, kimileri Türk mühendislerinin yetersizliklerini eleştirir. Öteki otomobil ile Anıtkabir’e gidildiğinden hiç söz edilmez. Bunca paranın boşa gittiğinden bahsedilir ancak; mekanize duruma geçmekte olan Türkiye’nin, at yetiştirmek için yirmi beş milyon TL harcamasından hiç söz eden olmaz… Bu duruma, 27 Mayıs 1960 devrimine bir tepki (darbe de diyebilirsiniz) nedenlerden biridir. Bir diğer neden, “devrim” sözcüğüne duyulan alerjidir. Süleyman Demirel devrim sözcüğünden nefret eder… Seri üretime 1964’te geçilmesi planlanırken maalesef proje rafa kaldırılır.
Seri üretimi devam etseydi, belki de gelişip zenginleşen bir otomobil sanayiimiz olacaktı. Çünkü, bakıyoruz da o zamanlar otomobil sanayi diye bir şeyi olmayan Japonya ve Güney Kore nerelere varmışlar… Çıkarları zedelenenler, bu durumu engellemek için ellerinden geleni yaptılar, hala da yapmaktalar. Bugün yabancı patent sahiplerinin ekmeğine yağ sürmekteler.
Bütün bulara karşılık “Devrim Otomobil” hala ayaktadır. Üretilen dört otomobilden bir “devrim” Eskişehir TULOMSAŞ bahçesine yapılan özel garaj müzesinde sergilenmektedir ve çalışır durumdadır.
Kaynak : http://www.hafif.org/yazi/devrim-otomobil-oykusu
Tasarım Kalıpları Makale
Interface ve soyut sınıflar , Tasarım kalıpları ile ilgili makale ve kitaplar.
http://www.kurumsaljava.com/2008/11/24/tasarim-prensipleri/
http://www.kurumsaljava.com/2008/11/24/tasarim-prensipleri/
Wednesday, October 8, 2008
Şiir (Cemal Süreyya)
“Son kötü günleri yaşıyoruz belki/
İlk güzel günleri de yaşarız belki/
Kekre bir şey var bu havada/
Geçmişle gelecek arasında/
Acıyla sevinç arasında/
Öfkeyle bağış arasında...”
İlk güzel günleri de yaşarız belki/
Kekre bir şey var bu havada/
Geçmişle gelecek arasında/
Acıyla sevinç arasında/
Öfkeyle bağış arasında...”
Sunday, September 28, 2008
Bayram öncesi (Hakkı Yalçın - Alıntıdır)
Bayram öncesi
Yazdığımız mektuplar vardı, adreslerini yitirdiğimiz. Bayram kartlarımız vardı.
Cep telefonlu teknik çağa yenik düştükten sonra, hepsinin anlamını da yitirdik.
Yeniden icat ettiğimiz kurallarla, sevgisizliğin hangi sokaklarında dolaşıyoruz kim bilir! O yüzden ölümler sıradanlaştı.
Saygısızlık ülke sınırlarını aştı.
Her bayram öncesinde, neler kaybettiğimizi daha iyi anlıyoruz.
***
El örgü kazaklarımız vardı, şimdi tel örgüler arkasında düşlerimiz var.
Ağzı bozulmuş politikanın.
Sadece paranın dediği oluyor.
Demokrasi sizlere ömür.
Cep telefonları sevgi ve saygı haramisi.
***
Televizyon reklamlarında, torununa şimdiki Ramazanlar'ın güzelliğini anlatan dede, örnek olarak "bonusu" gösteriyor.
Tüketimin getirisini.
Gösterecek başka bir güzelliği yok çünkü!
Dünü de kendine çekiyor sistem, yarını da.
Dedeleri de yanına çekiyor, torunları da...
***
Mektupları yitirmekle, neleri yitirdiğimizi fark etmedik. Ihlamur kokusunu unuttuk, poşetli çaylara yenik düşerken.
Kalplerin içinde kalan, fotoğraflı kalp kolyelerin dışında kaldık.
Bir masaldık o mektuplarda.
Birimiz hepimiz içindi, hepimiz birimiz için...
Şimdi cebinizdeki telefona sorun bakalım, böyle bir cömertliğe izin verecek mi?
Televizyonlara akıl danışın bakalım, sabah programlarında hayatınızın hikayesi kaç para ediyor?
***
Sizleri iliğinize kadar sömürenler, içinizdeki sevgileri bile kuruttular da, haberiniz yok.
Sizin sadece telefonlarınız var.
Kire batmış televizyonlarınız.
Bizim mektuplarımız hala duruyor.
Telefonda mesajlar yerine, bayram kartlarımızı kullanıyoruz inatla.
Bizler mazi gazileriyiz.
Hala aşktan yaralı, hala bayramlarda el öpecek büyüklerini arayan...
***
Kadir Gecesi'nde ne çok kandil mesajı çekildi...
Sizler büyüklerinizin kandilini mesajla kutlarken, telefon şirketleri ikiye katladı kazancını...
Giden sadece para olsa neyse...
Geleneklerimiz gitti...
Mektuplar gibi... Saygılar gibi...
http://www.takvim.com.tr/yaz1206-3140-117.html
Yazdığımız mektuplar vardı, adreslerini yitirdiğimiz. Bayram kartlarımız vardı.
Cep telefonlu teknik çağa yenik düştükten sonra, hepsinin anlamını da yitirdik.
Yeniden icat ettiğimiz kurallarla, sevgisizliğin hangi sokaklarında dolaşıyoruz kim bilir! O yüzden ölümler sıradanlaştı.
Saygısızlık ülke sınırlarını aştı.
Her bayram öncesinde, neler kaybettiğimizi daha iyi anlıyoruz.
***
El örgü kazaklarımız vardı, şimdi tel örgüler arkasında düşlerimiz var.
Ağzı bozulmuş politikanın.
Sadece paranın dediği oluyor.
Demokrasi sizlere ömür.
Cep telefonları sevgi ve saygı haramisi.
***
Televizyon reklamlarında, torununa şimdiki Ramazanlar'ın güzelliğini anlatan dede, örnek olarak "bonusu" gösteriyor.
Tüketimin getirisini.
Gösterecek başka bir güzelliği yok çünkü!
Dünü de kendine çekiyor sistem, yarını da.
Dedeleri de yanına çekiyor, torunları da...
***
Mektupları yitirmekle, neleri yitirdiğimizi fark etmedik. Ihlamur kokusunu unuttuk, poşetli çaylara yenik düşerken.
Kalplerin içinde kalan, fotoğraflı kalp kolyelerin dışında kaldık.
Bir masaldık o mektuplarda.
Birimiz hepimiz içindi, hepimiz birimiz için...
Şimdi cebinizdeki telefona sorun bakalım, böyle bir cömertliğe izin verecek mi?
Televizyonlara akıl danışın bakalım, sabah programlarında hayatınızın hikayesi kaç para ediyor?
***
Sizleri iliğinize kadar sömürenler, içinizdeki sevgileri bile kuruttular da, haberiniz yok.
Sizin sadece telefonlarınız var.
Kire batmış televizyonlarınız.
Bizim mektuplarımız hala duruyor.
Telefonda mesajlar yerine, bayram kartlarımızı kullanıyoruz inatla.
Bizler mazi gazileriyiz.
Hala aşktan yaralı, hala bayramlarda el öpecek büyüklerini arayan...
***
Kadir Gecesi'nde ne çok kandil mesajı çekildi...
Sizler büyüklerinizin kandilini mesajla kutlarken, telefon şirketleri ikiye katladı kazancını...
Giden sadece para olsa neyse...
Geleneklerimiz gitti...
Mektuplar gibi... Saygılar gibi...
http://www.takvim.com.tr/yaz1206-3140-117.html
Monday, September 1, 2008
How To Demo Your Startup
Jason Calacanis’ most recent post to his email mailing list is particularly relevant to our audience. He’s spoken with 200 companies in ten minute increments as they give their pitch to be a part of the upcoming TechCrunch50 conference. I agree with all of his thoughts below based on my own experience getting pitched from thousands of startups over the last three years. If you are pitching a company to the press, a conference, a potential employee or an investor, bookmark this. You’ll be glad you did.
The best chance for success of course is to have a killer product to show. In which case it doesn’t really matter if you show up late to the call and do it from a cell phone while sitting in an underground parking garage with the music playing. But on the margin advice like this is hugely valuable because it helps the listener understand exactly what your product is, and how clearly you understand the challenges ahead of you.
The full text of Jason’s email is below. You can request to join the mailing list here.
For the past 10 days I’ve sat through 200 company demos for the TechCrunch50 conference. These demos are mostly done over the phone for 10 minutes using the phone and web conferencing software like WebEx or Adobe’s wonderful new “Connect” service.
After doing 2,500 minutes of demos (40 hours) this year and many more last year for the conference, I’ve learned a lot about what makes for a great demo and what makes for a horrible demo. Since demoing your idea is a key to your success as an entrepreneur, I thought I would share everything I know in a few simple bullet points.
These tips are applicable to presenting in front of an investor, a partner as well as a demo style conference. Of course, every situation is different so consider these loose guidelines.
Background: The TechCrunch50 conference is taking places on September 8-10th in San Francisco and you can find more information here: www.techcrunch50.com. Mike Arrington of TechCrunch.com and I started the event last year as a place where fifty startup companies could launch their products without having to pay a fee (i.e. the incumbent conference called DEMO charges $18,500 to launch a startup company–that’s really low/abusive in my book). Google, Microsoft, Yahoo, Sequoia Capital and a bunch of other fine partners have joined us in hosting the event.
1. Show your product within the first 60 seconds
——————————————-
Most folks start their presentations with information like the size of the market they are tackling (tens of billions, we only need 1%!), their inflated corporate bios, the philosophical approach they’re
taking, and boring Powerpoint graphics explaining some convoluted workflow of their product.
The longer it takes for you to show your product, the worse your product is. Folks who have a kick-ass product don’t spend five or ten minutes “setting the stage” or “giving the background.” Folks with killer products CAN’T WAIT to show you their product. Their demos start with their homepage and quickly jump into the users experience. If a picture tells a thousand stories, then a product demo tells a million.
Show your product immediately, and if you don’t have a product to show don’t take the meeting.
2. The best products take less than five minutes to demo
——————————————-
The greatest tech products over the past 10 years would take no more than five minutes each to demo. For example:
a) Larry and Sergey could demo Google search in less than five minutes. Here’s a box, type something in and you get a huge reward.
b) Steve Jobs could demo the iPod in less than five minutes. Plug it in, put in your CDs and it syncs your music. Turn it on and use the wheel to select what songs you want to listen to.
c) Chris DeWolfe could demo MySpace in less than five minutes. Sign up, fill out your profile, and add your friends. For bonus points add some widgets to your page.
I think you get the idea: the better the product the LESS time it takes to demo. If your product demo takes more than five minutes to demo, it probably sucks. All the tiny little features that matter to
you are of course important–God is in the details–however, when presenting your company, you don’t have to show them. Larry and Sergey wouldn’t open up the advanced search tab and the list of operators you can use in Google during a demo.
Steve Jobs does take the demo details to a fairly detailed level, but you and I are not Steve Jobs. There is only one Steve Jobs and there is only one Apple. You’re never going to build something as cool as Steve, and as such there is no need for you to talk about your product for five or ten minutes.
3. Leave people wanting more.
——————————————-
If you take my advice in point two, then folks should be either blown away or intrigued by your core product. If they are not somewhere in that spectrum, you need to rebuild your core product.
When I pitched Mahalo to investors, I had five sheets of paper with different search results on each. I put them on a table and said which one is the best. Obviously I knew my result was the best, and that
simple demonstration lead to MASSIVE discussion: how was the page built? how long did it take to build? what would it cost to make that page? how often do you need to update it? how can you scale that business? how many pages can you create before it breaks even?
It’s best for folks to discover the merits of your product for themselves, and it’s up to you to make such a compelling core product that they are intrigued enough to explore it.
4. Talk about what you’ve done, not what you’re going to do.
——————————————-
Weak startups and their leaders seem to immediately start talk about “what’s next,” as opposed to focusing on the core product. Anyone can say we’re going to add: a mobile version, collaborative filtering, an advertising network, visualizations, a marketplace, a browser plugin, a browser and a social network to their product. In fact, given the amount of open source and off the shelf software out there, combined with the large number of developers in the world, anyone can bolt these things on to their service in a week or three.
Who cares what you’re going to bolt on to your startup? What really matters is the core functionality of your startup.
Steve Jobs has become at once the world’s greatest salesman and product developer because he only announces Apple’s achievements. He doesn’t waste time on what Apple’s going to do: he talks about the here and now. Microsoft’s old strategy was to talk about products that were coming and that put them in the horrible position of having to backpedal when they changed their mind about a product.
5. Understand your competitive landscape–current and historical.
——————————————-
This year I’ve had three companies show me group SMS messaging products, and most of them did not know what UPOC.com was (Gordon Gould’s group SMS messaging service that was five years ahead of its time). I’ve had three or four companies over the past two years of TechCrunch50 conferences pitch me on Third Voice–the controversial “web annotation” service from Web 1.0. [Side note: I loved the concept of Third Voice so much I considered starting a company like it and even bought the domain name annotated.com.]
When I pitched the idea for Weblogs, Inc. to Mark Cuban, Yossi Vardi and Jeff Bezos, I understood all the niche email marketing and newsletter companies from the early and mid-nineties cold. I researched why they worked and why they failed, and I knew which ones were sold and bought and by whom. When I pitched Mahalo to Sequoia Capital, I knew the history of human-powered search and directories from DMOZ to Yahoo Directory to LookSmart.
If you don’t know the competitive landscape, and the shoulder’s you’re standing on, folks are not going to be comfortable giving you their money, time or attention.
6. Short answers are best.
——————————————-
When taking questions about your product answer questions shortly. This is a very challenging thing for many people–including myself–to do. If you’re like me, you’ve probably thought out your startup’s
issues a thousand different ways. When I sit at the poker table I play a game where I think out every possible scenario for not only my hands, but the hands of my opponents (this is fairly standard among
advanced poker players from what I understand).
Say I have Ace King and I raised out of position and the button called my raise pre-flop. Then they re-raised me on the flop, which had an Ace. What does that tell me? They could have an ace, they could have two aces and have slow played me, they could have a medium pocket pair and they want to see if I have an ace, maybe they are on a flush or straight draw or maybe they suck at poker. Who the hell knows?!?! You can go insane trying to figure all these things out–that’s why poker
becomes very addictive.
The point is all that inner thinking is chaos when you try to explain it to another person. It’s pure madness after 60 seconds of talking. The best thing to do is answer the question with the most concise answer. For example, when asked “what happens if Google enters your market?” answer quickly and with confidence:
a) Google has entered many markets, but they are only #1 in search and search advertising. They trail in social networking to MySpace and Facebook, in classifieds to Craigslist, in news to Yahoo and AOL, in email to Microsoft, AOL, and Yahoo, and in instant messaging to Microsoft, AOL, and Yahoo.
b) We’re not sure if Google will enter our market, but hopefully we’ll have developed our product enough that it will be a real sustainable business by that time.
c) We think Google might enter our market at some point, and if they do they and their competitors will certainly consider buying us–creating a bidding war for our entrenched position.
d) Google is a very big company right now with a very big cash machine that they have to focus on and protect–they will never do our business with our level of focus. We will out execute them on all
fronts.
These are all amazing answers (I did, after all, come up with them), and you can say them in around a minute. However, if you cram all four of these sentences together you’ve spoken for five minutes.
7. PowerPoint bullet slides are death
——————————————-
Do not make slide after slide explaining your business in bullet points, because it’s really, really boring. Powerpoint/Keynote slides that are not boring include charts, product shots, feature set tables
and the like. Things that explain big concepts with ease and grace are great, but bullet points of obvious facts show that:
a) you don’t have the ability to create a compelling story with data
b) you don’t think that much of the person being presented the information
I’m not a huge fan of “funny slides” or lots of graphics for graphics sake. You’re not pitching your company to get laughs–unless you’re on stage–you’re doing it to raise capital, close a partnership or get on stage at a conference. Keep it focused and to the point.
8. How to use this new device called the phone.
——————————————-
When presenting over the phone use a handset and a land-line… only!
It’s amazing to me that any person doing a business call would conduct it on their mobile phone. Mobile phones sound horrible 95% of the time, and they frequently cut out. If you are presenting your company take it seriously and get yourself to a landline. You have limited time and don’t want folks to miss a single word.
Speakerphones are horrible, and putting the person receiving the demo on speaker phone during a demo is just disrespectful. You can hear all the rustling, side conversations and horrible echos when you’re on speaker phone. When doing a demo pick up the handset and speak. If you go to a Q&A session then use speaker phone. That’s why it exists.
Only use a headset if it is very, very high-fidelity and you have the microphone right up to your mouth. Also, don’t eat, drink or breath heavy into the microphone or you run the risk of sounding like an animal. I use an amazing Plantronics headset, and I like me some Green Matcha tea, but I hit the mute key when I sip!
I know it sounds crazy to have a discussion about how to use the phone, but the majority of these young people actually think it’s acceptable to have two or three drop offs in a call–it’s not. Grow up
and get a land line.
9. How to handle questions you don’t know the answer to
——————————————-
After you do your concise presentation you’re hopefully going to get a lot of questions. Here are some important tips to consider when you don’t know the answer cold:
a) take a moment to think about the question. You can even say “Hmmm… that’s a good question. Let me think about that for a second.” Folks appreciate a little consideration when someone takes a
question.
b) if you don’t have an answer be honest and say you don’t. There are many ways to say this including: “I’m not really sure, I’m going to have to think about that for a bit and get back to you,” or “I’m not sure to be honest. What do you think?”
c) feel free to think out loud and brainstorm with the person. You can do this by saying “I’ve never really considered that. Perhaps you can expand the question a little and we can explore it right now.”
d) if you’re not sure of the answer you can always say you’ll cross that bridge when you come to it. “I’m not sure how we would deal with a sudden spike in the cost of bandwidth, we would have to collect more information and answer that question down the road. It is a manageable risk factor I suppose. ”
The worst thing to do when you don’t have an answer is b.s. the person. No one has an answer for everything, except a b.s. artists. So, feel free to say you don’t know–folks find it refreshingly humble
and honest.
10. Always confirm the time of your meeting/call, and always be 15
minutes early.
——————————————-
People are really busy and meetings get mixed up. Every meeting or phone call I do is confirmed twice: once by email, and once on the day before the meeting. Reconfirming meetings makes you look like a true player and it costs you nothing. You do this by sending a simple email saying “Looking forward to seeing you tomorrow at your offices at 123 Main Street at 3pm. If anything changes you can reach me on my mobile at 310-555-1212.”
Also, be early. Come on. If you’re doing a meeting with someone who might invest in your company, do a business deal with you, etc., you can show a lot of respect by being in their lobby or on hold on the conference call five to 15 minutes ahead of time. Don’t show up more than 15 minutes ahead of time or you’ll look like a stalker. If you get to your meeting 45 minutes ahead of time go to the Starbucks and buy yourself a treat for being so on top of things. :-)
What are your best tips for giving a proper demo of your company on the phone or in person?
In your mind, what are the worst things folks have done during a presentation?
http://www.techcrunch.com/2008/08/09/how-to-demo-your-startup/
The best chance for success of course is to have a killer product to show. In which case it doesn’t really matter if you show up late to the call and do it from a cell phone while sitting in an underground parking garage with the music playing. But on the margin advice like this is hugely valuable because it helps the listener understand exactly what your product is, and how clearly you understand the challenges ahead of you.
The full text of Jason’s email is below. You can request to join the mailing list here.
For the past 10 days I’ve sat through 200 company demos for the TechCrunch50 conference. These demos are mostly done over the phone for 10 minutes using the phone and web conferencing software like WebEx or Adobe’s wonderful new “Connect” service.
After doing 2,500 minutes of demos (40 hours) this year and many more last year for the conference, I’ve learned a lot about what makes for a great demo and what makes for a horrible demo. Since demoing your idea is a key to your success as an entrepreneur, I thought I would share everything I know in a few simple bullet points.
These tips are applicable to presenting in front of an investor, a partner as well as a demo style conference. Of course, every situation is different so consider these loose guidelines.
Background: The TechCrunch50 conference is taking places on September 8-10th in San Francisco and you can find more information here: www.techcrunch50.com. Mike Arrington of TechCrunch.com and I started the event last year as a place where fifty startup companies could launch their products without having to pay a fee (i.e. the incumbent conference called DEMO charges $18,500 to launch a startup company–that’s really low/abusive in my book). Google, Microsoft, Yahoo, Sequoia Capital and a bunch of other fine partners have joined us in hosting the event.
1. Show your product within the first 60 seconds
——————————————-
Most folks start their presentations with information like the size of the market they are tackling (tens of billions, we only need 1%!), their inflated corporate bios, the philosophical approach they’re
taking, and boring Powerpoint graphics explaining some convoluted workflow of their product.
The longer it takes for you to show your product, the worse your product is. Folks who have a kick-ass product don’t spend five or ten minutes “setting the stage” or “giving the background.” Folks with killer products CAN’T WAIT to show you their product. Their demos start with their homepage and quickly jump into the users experience. If a picture tells a thousand stories, then a product demo tells a million.
Show your product immediately, and if you don’t have a product to show don’t take the meeting.
2. The best products take less than five minutes to demo
——————————————-
The greatest tech products over the past 10 years would take no more than five minutes each to demo. For example:
a) Larry and Sergey could demo Google search in less than five minutes. Here’s a box, type something in and you get a huge reward.
b) Steve Jobs could demo the iPod in less than five minutes. Plug it in, put in your CDs and it syncs your music. Turn it on and use the wheel to select what songs you want to listen to.
c) Chris DeWolfe could demo MySpace in less than five minutes. Sign up, fill out your profile, and add your friends. For bonus points add some widgets to your page.
I think you get the idea: the better the product the LESS time it takes to demo. If your product demo takes more than five minutes to demo, it probably sucks. All the tiny little features that matter to
you are of course important–God is in the details–however, when presenting your company, you don’t have to show them. Larry and Sergey wouldn’t open up the advanced search tab and the list of operators you can use in Google during a demo.
Steve Jobs does take the demo details to a fairly detailed level, but you and I are not Steve Jobs. There is only one Steve Jobs and there is only one Apple. You’re never going to build something as cool as Steve, and as such there is no need for you to talk about your product for five or ten minutes.
3. Leave people wanting more.
——————————————-
If you take my advice in point two, then folks should be either blown away or intrigued by your core product. If they are not somewhere in that spectrum, you need to rebuild your core product.
When I pitched Mahalo to investors, I had five sheets of paper with different search results on each. I put them on a table and said which one is the best. Obviously I knew my result was the best, and that
simple demonstration lead to MASSIVE discussion: how was the page built? how long did it take to build? what would it cost to make that page? how often do you need to update it? how can you scale that business? how many pages can you create before it breaks even?
It’s best for folks to discover the merits of your product for themselves, and it’s up to you to make such a compelling core product that they are intrigued enough to explore it.
4. Talk about what you’ve done, not what you’re going to do.
——————————————-
Weak startups and their leaders seem to immediately start talk about “what’s next,” as opposed to focusing on the core product. Anyone can say we’re going to add: a mobile version, collaborative filtering, an advertising network, visualizations, a marketplace, a browser plugin, a browser and a social network to their product. In fact, given the amount of open source and off the shelf software out there, combined with the large number of developers in the world, anyone can bolt these things on to their service in a week or three.
Who cares what you’re going to bolt on to your startup? What really matters is the core functionality of your startup.
Steve Jobs has become at once the world’s greatest salesman and product developer because he only announces Apple’s achievements. He doesn’t waste time on what Apple’s going to do: he talks about the here and now. Microsoft’s old strategy was to talk about products that were coming and that put them in the horrible position of having to backpedal when they changed their mind about a product.
5. Understand your competitive landscape–current and historical.
——————————————-
This year I’ve had three companies show me group SMS messaging products, and most of them did not know what UPOC.com was (Gordon Gould’s group SMS messaging service that was five years ahead of its time). I’ve had three or four companies over the past two years of TechCrunch50 conferences pitch me on Third Voice–the controversial “web annotation” service from Web 1.0. [Side note: I loved the concept of Third Voice so much I considered starting a company like it and even bought the domain name annotated.com.]
When I pitched the idea for Weblogs, Inc. to Mark Cuban, Yossi Vardi and Jeff Bezos, I understood all the niche email marketing and newsletter companies from the early and mid-nineties cold. I researched why they worked and why they failed, and I knew which ones were sold and bought and by whom. When I pitched Mahalo to Sequoia Capital, I knew the history of human-powered search and directories from DMOZ to Yahoo Directory to LookSmart.
If you don’t know the competitive landscape, and the shoulder’s you’re standing on, folks are not going to be comfortable giving you their money, time or attention.
6. Short answers are best.
——————————————-
When taking questions about your product answer questions shortly. This is a very challenging thing for many people–including myself–to do. If you’re like me, you’ve probably thought out your startup’s
issues a thousand different ways. When I sit at the poker table I play a game where I think out every possible scenario for not only my hands, but the hands of my opponents (this is fairly standard among
advanced poker players from what I understand).
Say I have Ace King and I raised out of position and the button called my raise pre-flop. Then they re-raised me on the flop, which had an Ace. What does that tell me? They could have an ace, they could have two aces and have slow played me, they could have a medium pocket pair and they want to see if I have an ace, maybe they are on a flush or straight draw or maybe they suck at poker. Who the hell knows?!?! You can go insane trying to figure all these things out–that’s why poker
becomes very addictive.
The point is all that inner thinking is chaos when you try to explain it to another person. It’s pure madness after 60 seconds of talking. The best thing to do is answer the question with the most concise answer. For example, when asked “what happens if Google enters your market?” answer quickly and with confidence:
a) Google has entered many markets, but they are only #1 in search and search advertising. They trail in social networking to MySpace and Facebook, in classifieds to Craigslist, in news to Yahoo and AOL, in email to Microsoft, AOL, and Yahoo, and in instant messaging to Microsoft, AOL, and Yahoo.
b) We’re not sure if Google will enter our market, but hopefully we’ll have developed our product enough that it will be a real sustainable business by that time.
c) We think Google might enter our market at some point, and if they do they and their competitors will certainly consider buying us–creating a bidding war for our entrenched position.
d) Google is a very big company right now with a very big cash machine that they have to focus on and protect–they will never do our business with our level of focus. We will out execute them on all
fronts.
These are all amazing answers (I did, after all, come up with them), and you can say them in around a minute. However, if you cram all four of these sentences together you’ve spoken for five minutes.
7. PowerPoint bullet slides are death
——————————————-
Do not make slide after slide explaining your business in bullet points, because it’s really, really boring. Powerpoint/Keynote slides that are not boring include charts, product shots, feature set tables
and the like. Things that explain big concepts with ease and grace are great, but bullet points of obvious facts show that:
a) you don’t have the ability to create a compelling story with data
b) you don’t think that much of the person being presented the information
I’m not a huge fan of “funny slides” or lots of graphics for graphics sake. You’re not pitching your company to get laughs–unless you’re on stage–you’re doing it to raise capital, close a partnership or get on stage at a conference. Keep it focused and to the point.
8. How to use this new device called the phone.
——————————————-
When presenting over the phone use a handset and a land-line… only!
It’s amazing to me that any person doing a business call would conduct it on their mobile phone. Mobile phones sound horrible 95% of the time, and they frequently cut out. If you are presenting your company take it seriously and get yourself to a landline. You have limited time and don’t want folks to miss a single word.
Speakerphones are horrible, and putting the person receiving the demo on speaker phone during a demo is just disrespectful. You can hear all the rustling, side conversations and horrible echos when you’re on speaker phone. When doing a demo pick up the handset and speak. If you go to a Q&A session then use speaker phone. That’s why it exists.
Only use a headset if it is very, very high-fidelity and you have the microphone right up to your mouth. Also, don’t eat, drink or breath heavy into the microphone or you run the risk of sounding like an animal. I use an amazing Plantronics headset, and I like me some Green Matcha tea, but I hit the mute key when I sip!
I know it sounds crazy to have a discussion about how to use the phone, but the majority of these young people actually think it’s acceptable to have two or three drop offs in a call–it’s not. Grow up
and get a land line.
9. How to handle questions you don’t know the answer to
——————————————-
After you do your concise presentation you’re hopefully going to get a lot of questions. Here are some important tips to consider when you don’t know the answer cold:
a) take a moment to think about the question. You can even say “Hmmm… that’s a good question. Let me think about that for a second.” Folks appreciate a little consideration when someone takes a
question.
b) if you don’t have an answer be honest and say you don’t. There are many ways to say this including: “I’m not really sure, I’m going to have to think about that for a bit and get back to you,” or “I’m not sure to be honest. What do you think?”
c) feel free to think out loud and brainstorm with the person. You can do this by saying “I’ve never really considered that. Perhaps you can expand the question a little and we can explore it right now.”
d) if you’re not sure of the answer you can always say you’ll cross that bridge when you come to it. “I’m not sure how we would deal with a sudden spike in the cost of bandwidth, we would have to collect more information and answer that question down the road. It is a manageable risk factor I suppose. ”
The worst thing to do when you don’t have an answer is b.s. the person. No one has an answer for everything, except a b.s. artists. So, feel free to say you don’t know–folks find it refreshingly humble
and honest.
10. Always confirm the time of your meeting/call, and always be 15
minutes early.
——————————————-
People are really busy and meetings get mixed up. Every meeting or phone call I do is confirmed twice: once by email, and once on the day before the meeting. Reconfirming meetings makes you look like a true player and it costs you nothing. You do this by sending a simple email saying “Looking forward to seeing you tomorrow at your offices at 123 Main Street at 3pm. If anything changes you can reach me on my mobile at 310-555-1212.”
Also, be early. Come on. If you’re doing a meeting with someone who might invest in your company, do a business deal with you, etc., you can show a lot of respect by being in their lobby or on hold on the conference call five to 15 minutes ahead of time. Don’t show up more than 15 minutes ahead of time or you’ll look like a stalker. If you get to your meeting 45 minutes ahead of time go to the Starbucks and buy yourself a treat for being so on top of things. :-)
What are your best tips for giving a proper demo of your company on the phone or in person?
In your mind, what are the worst things folks have done during a presentation?
http://www.techcrunch.com/2008/08/09/how-to-demo-your-startup/
Thursday, July 24, 2008
Top 10 Concepts That Every Software Engineer Should Know
Kaynak : http://www.readwriteweb.com/archives/top_10_concepts_that_every_software_engineer_should_know.php
Top 10 Concepts That Every Software Engineer Should Know
Written by Alex Iskold / July 22, 2008 8:21 PM / 38 Comments
The future of software development is about good craftsmen. With infrastructure like Amazon Web Services and an abundance of basic libraries, it no longer takes a village to build a good piece of software.
These days, a couple of engineers who know what they are doing can deliver complete systems. In this post, we discuss the top 10 concepts software engineers should know to achieve that.
A successful software engineer knows and uses design patterns, actively refactors code, writes unit tests and religiously seeks simplicity. Beyond the basic methods, there are concepts that good software engineers know about. These transcend programming languages and projects - they are not design patterns, but rather broad areas that you need to be familiar with. The top 10 concepts are:
1. Interfaces
2. Conventions and Templates
3. Layering
4. Algorithmic Complexity
5. Hashing
6. Caching
7. Concurrency
8. Cloud Computing
9. Security
10. Relational Databases
10. Relational Databases
Relational Databases have recently been getting a bad name because they cannot scale well to support massive web services. Yet this was one of the most fundamental achievements in computing that has carried us for two decades and will remain for a long time. Relational databases are excellent for order management systems, corporate databases and P&L data.
At the core of the relational database is the concept of representing information in records. Each record is added to a table, which defines the type of information. The database offers a way to search the records using a query language, nowadays SQL. The database offers a way to correlate information from multiple tables.
The technique of data normalization is about correct ways of partitioning the data among tables to minimize data redundancy and maximize the speed of retrieval.
9. Security
With the rise of hacking and data sensitivity, the security is paramount. Security is a broad topic that includes authentication, authorization, and information transmission.
Authentication is about verifying user identity. A typical website prompts for a password. The authentication typically happens over SSL (secure socket layer), a way to transmit encrypted information over HTTP. Authorization is about permissions and is important in corporate systems, particularly those that define workflows. The recently developed OAuth protocol helps web services to enable users to open access to their private information. This is how Flickr permits access to individual photos or data sets.
Another security area is network protection. This concerns operating systems, configuration and monitoring to thwart hackers. Not only network is vulnerable, any piece of software is. Firefox browser, marketed as the most secure, has to patch the code continuously. To write secure code for your system requires understanding specifics and potential problems.
8. Cloud Computing
In our recent post Reaching For The Sky Through Compute Clouds we talked about how commodity cloud computing is changing the way we deliver large-scale web applications. Massively parallel, cheap cloud computing reduces both costs and time to market.
Cloud computing grew out of parallel computing, a concept that many problems can be solved faster by running the computations in parallel.
After parallel algorithms came grid computing, which ran parallel computations on idle desktops. One of the first examples was SETI@home project out of Berkley, which used spare CPU cycles to crunch data coming from space. Grid computing is widely adopted by financial companies, which run massive risk calculations. The concept of under-utilized resources, together with the rise of J2EE platform, gave rise to the precursor of cloud computing: application server virtualization. The idea was to run applications on demand and change what is available depending on the time of day and user activity.
Today's most vivid example of cloud computing is Amazon Web Services, a package available via API. Amazon's offering includes a cloud service (EC2), a database for storing and serving large media files (S3), an indexing service (SimpleDB), and the Queue service (SQS). These first blocks already empower an unprecedented way of doing large-scale computing, and surely the best is yet to come.
7. Concurrency
Concurrency is one topic engineers notoriously get wrong, and understandibly so, because the brain does juggle many things at a time and in schools linear thinking is emphasized. Yet concurrency is important in any modern system.
Concurrency is about parallelism, but inside the application. Most modern languages have an in-built concept of concurrency; in Java, it's implemented using Threads.
A classic concurrency example is the producer/consumer, where the producer generates data or tasks, and places it for worker threads to consume and execute. The complexity in concurrency programming stems from the fact Threads often needs to operate on the common data. Each Thread has its own sequence of execution, but accesses common data. One of the most sophisticated concurrency libraries has been developed by Doug Lea and is now part of core Java.
6. Caching
No modern web system runs without a cache, which is an in-memory store that holds a subset of information typically stored in the database. The need for cache comes from the fact that generating results based on the database is costly. For example, if you have a website that lists books that were popular last week, you'd want to compute this information once and place it into cache. User requests fetch data from the cache instead of hitting the database and regenerating the same information.
Caching comes with a cost. Only some subsets of information can be stored in memory. The most common data pruning strategy is to evict items that are least recently used (LRU). The prunning needs to be efficient, not to slow down the application.
A lot of modern web applications, including Facebook, rely on a distributed caching system called Memcached, developed by Brad Firzpatrick when working on LiveJournal. The idea was to create a caching system that utilises spare memory capacity on the network. Today, there are Memcached libraries for many popular languages, including Java and PHP.
5. Hashing
The idea behind hashing is fast access to data. If the data is stored sequentially, the time to find the item is proportional to the size of the list. For each element, a hash function calculates a number, which is used as an index into the table. Given a good hash function that uniformly spreads data along the table, the look-up time is constant. Perfecting hashing is difficult and to deal with that hashtable implementations support collision resolution.
Beyond the basic storage of data, hashes are also important in distributed systems. The so-called uniform hash is used to evenly allocate data among computers in a cloud database. A flavor of this technique is part of Google's indexing service; each URL is hashed to particular computer. Memcached similarly uses a hash function.
Hash functions can be complex and sophisticated, but modern libraries have good defaults. The important thing is how hashes work and how to tune them for maximum performance benefit.
4. Algorithmic Complexity
There are just a handful of things engineers must know about algorithmic complexity. First is big O notation. If something takes O(n) it's linear in the size of data. O(n^2) is quadratic. Using this notation, you should know that search through a list is O(n) and binary search (through a sorted list) is log(n). And sorting of n items would take n*log(n) time.
Your code should (almost) never have multiple nested loops (a loop inside a loop inside a loop). Most of the code written today should use Hashtables, simple lists and singly nested loops.
Due to abundance of excellent libraries, we are not as focused on efficiency these days. That's fine, as tuning can happen later on, after you get the design right.
Elegant algorithms and performance is something you shouldn't ignore. Writing compact and readable code helps ensure your algorithms are clean and simple.
3. Layering
Layering is probably the simplest way to discuss software architecture. It first got serious attention when John Lakos published his book about Large-scale C++ systems. Lakos argued that software consists of layers. The book introduced the concept of layering. The method is this. For each software component, count the number of other components it relies on. That is the metric of how complex the component is.
Lakos contended a good software follows the shape of a pyramid; i.e., there's a progressive increase in the cummulative complexity of each component, but not in the immediate complexity. Put differently, a good software system consists of small, reusable building blocks, each carrying its own responsibility. In a good system, no cyclic dependencies between components are present and the whole system is a stack of layers of functionality, forming a pyramid.
Lakos's work was a precursor to many developments in software engineering, most notably Refactoring. The idea behind refactoring is continuously sculpting the software to ensure it'is structurally sound and flexible. Another major contribution was by Dr Robert Martin from Object Mentor, who wrote about dependecies and acyclic architectures
Among tools that help engineers deal with system architecture are Structure 101 developed by Headway software, and SA4J developed by my former company, Information Laboratory, and now available from IBM.
2. Conventions and Templates
Naming conventions and basic templates are the most overlooked software patterns, yet probably the most powerful.
Naming conventions enable software automation. For example, Java Beans framework is based on a simple naming convention for getters and setters. And canonical URLs in del.icio.us: http://del.icio.us/tag/software take the user to the page that has all items tagged software.
Many social software utilise naming conventions in a similar way. For example, if your user name is johnsmith then likely your avatar is johnsmith.jpg and your rss feed is johnsmith.xml.
Naming conventions are also used in testing, for example JUnit automatically recognizes all the methods in the class that start with prefix test.
The templates are not C++ or Java language constructs. We're talking about template files that contain variables and then allow binding of objects, resolution, and rendering the result for the client.
Cold Fusion was one of the first to popularize templates for web applications. Java followed with JSPs, and recently Apache developed handy general purpose templating for Java called Velocity. PHP can be used as its own templating engine because it supports eval function (be careful with security). For XML programming it is standard to use XSL language to do templates.
From generation of HTML pages to sending standardized support emails, templates are an essential helper in any modern software system.
1. Interfaces
The most important concept in software is interface. Any good software is a model of a real (or imaginary) system. Understanding how to model the problem in terms of correct and simple interfaces is crucial. Lots of systems suffer from the extremes: clumped, lengthy code with little abstractions, or an overly designed system with unnecessary complexity and unused code.
Among the many books, Agile Programming by Dr Robert Martin stands out because of focus on modeling correct interfaces.
In modeling, there are ways you can iterate towards the right solution. Firstly, never add methods that might be useful in the future. Be minimalist, get away with as little as possible. Secondly, don't be afraid to recognize today that what you did yesterday wasn't right. Be willing to change things. Thirdly, be patient and enjoy the process. Ultimately you will arrive at a system that feels right. Until then, keep iterating and don't settle.
Conclusion
Modern software engineering is sophisticated and powerful, with decades of experience, millions of lines of supporting code and unprecidented access to cloud computing. Today, just a couple of smart people can create software that previously required the efforts of dozens of people. But a good craftsman still needs to know what tools to use, when and why.
In this post we discussed concepts that are indispensible for software engineers. And now tell us please what you would add to this list. Share with us what concepts you find indispensible in your daily software engineering journeys.
Top 10 Concepts That Every Software Engineer Should Know
Written by Alex Iskold / July 22, 2008 8:21 PM / 38 Comments
The future of software development is about good craftsmen. With infrastructure like Amazon Web Services and an abundance of basic libraries, it no longer takes a village to build a good piece of software.
These days, a couple of engineers who know what they are doing can deliver complete systems. In this post, we discuss the top 10 concepts software engineers should know to achieve that.
A successful software engineer knows and uses design patterns, actively refactors code, writes unit tests and religiously seeks simplicity. Beyond the basic methods, there are concepts that good software engineers know about. These transcend programming languages and projects - they are not design patterns, but rather broad areas that you need to be familiar with. The top 10 concepts are:
1. Interfaces
2. Conventions and Templates
3. Layering
4. Algorithmic Complexity
5. Hashing
6. Caching
7. Concurrency
8. Cloud Computing
9. Security
10. Relational Databases
10. Relational Databases
Relational Databases have recently been getting a bad name because they cannot scale well to support massive web services. Yet this was one of the most fundamental achievements in computing that has carried us for two decades and will remain for a long time. Relational databases are excellent for order management systems, corporate databases and P&L data.
At the core of the relational database is the concept of representing information in records. Each record is added to a table, which defines the type of information. The database offers a way to search the records using a query language, nowadays SQL. The database offers a way to correlate information from multiple tables.
The technique of data normalization is about correct ways of partitioning the data among tables to minimize data redundancy and maximize the speed of retrieval.
9. Security
With the rise of hacking and data sensitivity, the security is paramount. Security is a broad topic that includes authentication, authorization, and information transmission.
Authentication is about verifying user identity. A typical website prompts for a password. The authentication typically happens over SSL (secure socket layer), a way to transmit encrypted information over HTTP. Authorization is about permissions and is important in corporate systems, particularly those that define workflows. The recently developed OAuth protocol helps web services to enable users to open access to their private information. This is how Flickr permits access to individual photos or data sets.
Another security area is network protection. This concerns operating systems, configuration and monitoring to thwart hackers. Not only network is vulnerable, any piece of software is. Firefox browser, marketed as the most secure, has to patch the code continuously. To write secure code for your system requires understanding specifics and potential problems.
8. Cloud Computing
In our recent post Reaching For The Sky Through Compute Clouds we talked about how commodity cloud computing is changing the way we deliver large-scale web applications. Massively parallel, cheap cloud computing reduces both costs and time to market.
Cloud computing grew out of parallel computing, a concept that many problems can be solved faster by running the computations in parallel.
After parallel algorithms came grid computing, which ran parallel computations on idle desktops. One of the first examples was SETI@home project out of Berkley, which used spare CPU cycles to crunch data coming from space. Grid computing is widely adopted by financial companies, which run massive risk calculations. The concept of under-utilized resources, together with the rise of J2EE platform, gave rise to the precursor of cloud computing: application server virtualization. The idea was to run applications on demand and change what is available depending on the time of day and user activity.
Today's most vivid example of cloud computing is Amazon Web Services, a package available via API. Amazon's offering includes a cloud service (EC2), a database for storing and serving large media files (S3), an indexing service (SimpleDB), and the Queue service (SQS). These first blocks already empower an unprecedented way of doing large-scale computing, and surely the best is yet to come.
7. Concurrency
Concurrency is one topic engineers notoriously get wrong, and understandibly so, because the brain does juggle many things at a time and in schools linear thinking is emphasized. Yet concurrency is important in any modern system.
Concurrency is about parallelism, but inside the application. Most modern languages have an in-built concept of concurrency; in Java, it's implemented using Threads.
A classic concurrency example is the producer/consumer, where the producer generates data or tasks, and places it for worker threads to consume and execute. The complexity in concurrency programming stems from the fact Threads often needs to operate on the common data. Each Thread has its own sequence of execution, but accesses common data. One of the most sophisticated concurrency libraries has been developed by Doug Lea and is now part of core Java.
6. Caching
No modern web system runs without a cache, which is an in-memory store that holds a subset of information typically stored in the database. The need for cache comes from the fact that generating results based on the database is costly. For example, if you have a website that lists books that were popular last week, you'd want to compute this information once and place it into cache. User requests fetch data from the cache instead of hitting the database and regenerating the same information.
Caching comes with a cost. Only some subsets of information can be stored in memory. The most common data pruning strategy is to evict items that are least recently used (LRU). The prunning needs to be efficient, not to slow down the application.
A lot of modern web applications, including Facebook, rely on a distributed caching system called Memcached, developed by Brad Firzpatrick when working on LiveJournal. The idea was to create a caching system that utilises spare memory capacity on the network. Today, there are Memcached libraries for many popular languages, including Java and PHP.
5. Hashing
The idea behind hashing is fast access to data. If the data is stored sequentially, the time to find the item is proportional to the size of the list. For each element, a hash function calculates a number, which is used as an index into the table. Given a good hash function that uniformly spreads data along the table, the look-up time is constant. Perfecting hashing is difficult and to deal with that hashtable implementations support collision resolution.
Beyond the basic storage of data, hashes are also important in distributed systems. The so-called uniform hash is used to evenly allocate data among computers in a cloud database. A flavor of this technique is part of Google's indexing service; each URL is hashed to particular computer. Memcached similarly uses a hash function.
Hash functions can be complex and sophisticated, but modern libraries have good defaults. The important thing is how hashes work and how to tune them for maximum performance benefit.
4. Algorithmic Complexity
There are just a handful of things engineers must know about algorithmic complexity. First is big O notation. If something takes O(n) it's linear in the size of data. O(n^2) is quadratic. Using this notation, you should know that search through a list is O(n) and binary search (through a sorted list) is log(n). And sorting of n items would take n*log(n) time.
Your code should (almost) never have multiple nested loops (a loop inside a loop inside a loop). Most of the code written today should use Hashtables, simple lists and singly nested loops.
Due to abundance of excellent libraries, we are not as focused on efficiency these days. That's fine, as tuning can happen later on, after you get the design right.
Elegant algorithms and performance is something you shouldn't ignore. Writing compact and readable code helps ensure your algorithms are clean and simple.
3. Layering
Layering is probably the simplest way to discuss software architecture. It first got serious attention when John Lakos published his book about Large-scale C++ systems. Lakos argued that software consists of layers. The book introduced the concept of layering. The method is this. For each software component, count the number of other components it relies on. That is the metric of how complex the component is.
Lakos contended a good software follows the shape of a pyramid; i.e., there's a progressive increase in the cummulative complexity of each component, but not in the immediate complexity. Put differently, a good software system consists of small, reusable building blocks, each carrying its own responsibility. In a good system, no cyclic dependencies between components are present and the whole system is a stack of layers of functionality, forming a pyramid.
Lakos's work was a precursor to many developments in software engineering, most notably Refactoring. The idea behind refactoring is continuously sculpting the software to ensure it'is structurally sound and flexible. Another major contribution was by Dr Robert Martin from Object Mentor, who wrote about dependecies and acyclic architectures
Among tools that help engineers deal with system architecture are Structure 101 developed by Headway software, and SA4J developed by my former company, Information Laboratory, and now available from IBM.
2. Conventions and Templates
Naming conventions and basic templates are the most overlooked software patterns, yet probably the most powerful.
Naming conventions enable software automation. For example, Java Beans framework is based on a simple naming convention for getters and setters. And canonical URLs in del.icio.us: http://del.icio.us/tag/software take the user to the page that has all items tagged software.
Many social software utilise naming conventions in a similar way. For example, if your user name is johnsmith then likely your avatar is johnsmith.jpg and your rss feed is johnsmith.xml.
Naming conventions are also used in testing, for example JUnit automatically recognizes all the methods in the class that start with prefix test.
The templates are not C++ or Java language constructs. We're talking about template files that contain variables and then allow binding of objects, resolution, and rendering the result for the client.
Cold Fusion was one of the first to popularize templates for web applications. Java followed with JSPs, and recently Apache developed handy general purpose templating for Java called Velocity. PHP can be used as its own templating engine because it supports eval function (be careful with security). For XML programming it is standard to use XSL language to do templates.
From generation of HTML pages to sending standardized support emails, templates are an essential helper in any modern software system.
1. Interfaces
The most important concept in software is interface. Any good software is a model of a real (or imaginary) system. Understanding how to model the problem in terms of correct and simple interfaces is crucial. Lots of systems suffer from the extremes: clumped, lengthy code with little abstractions, or an overly designed system with unnecessary complexity and unused code.
Among the many books, Agile Programming by Dr Robert Martin stands out because of focus on modeling correct interfaces.
In modeling, there are ways you can iterate towards the right solution. Firstly, never add methods that might be useful in the future. Be minimalist, get away with as little as possible. Secondly, don't be afraid to recognize today that what you did yesterday wasn't right. Be willing to change things. Thirdly, be patient and enjoy the process. Ultimately you will arrive at a system that feels right. Until then, keep iterating and don't settle.
Conclusion
Modern software engineering is sophisticated and powerful, with decades of experience, millions of lines of supporting code and unprecidented access to cloud computing. Today, just a couple of smart people can create software that previously required the efforts of dozens of people. But a good craftsman still needs to know what tools to use, when and why.
In this post we discussed concepts that are indispensible for software engineers. And now tell us please what you would add to this list. Share with us what concepts you find indispensible in your daily software engineering journeys.
Subscribe to:
Posts (Atom)