This post contains the slides and associated commentary for a short presentation that I gave at the June 2014 Boston Front End Developers Meetup. You can also view the video of this event.


Hello, my name is Jeff Whelpley and I am the Chief Architect at GetHuman. A little over a year ago we decided to build our front end with AngularJS. In this presentation I will explain why we chose Angular over other alternatives like Ember or Backbone.

What is AngularJS

First, I think it is important to understand the three things that make Angular different than other frameworks and that make Angular special. Namely,

  1. Angular markup lives in the DOM
  2. Angular uses plain old JavaScript objects
  3. Angular heavily leverages Dependency Injection

DOM has markup

Templates in most client-side JavaScript frameworks work like something like this:

  • template with markup -> framework template engine -> HTML -> DOM

Angular, on the other hand puts markup directly into the HTML document and the flow looks like this:

  • HTML with Angular markup -> DOM -> Angular template engine

Angular evaluates the markup only after HTML has been loaded into the DOM.

So what?

Well, this approach has three major benefits.

  1. Integration with Existing Apps – Since Angular only starts evaluating the page at the end of the loading process (i.e. once HTML is in the DOM), it is very easy to sprinkle small bits of Angular “magic” on top of existing applications.
  2. Simplicity – You can work with Angular in a basic HTML document from you local file system. Just open the HTML document in your browser. No need for any web server or template build process. I have found this very useful for creating quick mockups of a new website or piece of functionality.
  3. Extensibility – Using Directives, Angular allows you to create custom elements and attributes that extend the standard HTML vocabulary. For example, in this slide there is a my-custom-tag element. Using Angular you can define how that element is rendered and assign behaviors to it. This allows you to create a library of your own reusable components.

Data is POJO

Angular is one of the only major front end frameworks that utilize plain old Javascript objects (POJOs) for the model layer. This makes it extremely easy to integrate with existing data sources and play with basic data.

Let’s say you make an AJAX call to get some data from an API. Before you can bind that data to the DOM, most frameworks require you to wrap the data in Model objects that have getters and setters. The getters/setters are how non-Angular frameworks propagate data change events.

Angular gets around this by using a process called dirty checking where snapshots of data over time are compared to see if anything has changed. While there are certainly some downsides to this approach (ex.$scope.$apply, data binding limits, etc.) I think the simplicity of using POJOs outweigh those downsides in most cases.

DI for modules

There are some people that love dependency injection and there are some people that hate it. If you are going to work with Angular, you sort of need to be in the former camp. I personally love it because it promotes better modularization of code and enables strong unit testing.

Unit testing front end code is usually hard because there are so many sticky dependencies. Angular’s DI allows you to mock out many of these dependencies and isolate individual components.


We don’t have enough time today to discuss every AngularJS feature, but I do want to point out a couple important ones.

  • Scope management – If you are going to create non-trivial web applications with Angular, you will have to take time to understand the way in which Angular isolates and shares data between components.
  • Animations – One of my favorite Angular features is the Animations library. Check out my buddy Matias Niemela’s blog on Animations. You will be amazed by how much you can accomplish with very little code.

Angular Toolbelt

One of the best things about Angular is that they made it very easy to build on top of the framework and to integrate with external libraries. This has allowed for the creation of very rich ecosystem. Here are some of the libraries outside of Angular that I use the most:

  • jQuery – Angular does not require jQuery, but it is needed if you want to use any jQuery plugin.
  • Angular UI – The UI Router and UI Bootstrap libraries are indepensible.
  • AngularFire – Similar to GoAngular, an easy way to hook your Angular app up to a realtime backend.
  • Ionic – A great mobile web app framework that works on top of Angular.

Why choose Angular?

Why should you choose to use Angular on your current project?

Before I answer this, let me takes a step back.

Why choose x?

Why you would choose any framework over another one? For me, the things on the left side of the slide are more important than the things on the right side.

Left side

  • Ease of maintenance – When there is a problem, I don’t want to spend hours debugging. I should be able to make day-to-day minor changes with ease.
  • Efficiency of building new features – When I want to build something new, does the framework help me or hinder me?
  • Engagement of the community – When the community is large and strong, it can overcome many issues within the framework. The community contributes to the framework, but then also builds many complentary libraries that work alongside the framework and make it even more powerful.

Right side

  • Current features – Features of course matter, but if you are making a decision for the long haul you shouldn’t be concerned about missing features if the current ones get you 80% of the way there and the stuff on the left side is all in place. For example, the Angular router is not that good, but the community built the UI Router which is a lot better.
  • Current performance – I care A LOT about performance, but the reality is that most front end Javascript frameworks are plenty fast enough. I am sure the React is faster in certain use cases and CanJS can spin a graphical image faster than anyone, but most of the performance differences are marginal and won’t be noticable in a majority of web apps.
  • Current learning curve – Everyone loves to talk about learning curves when comparing frameworks and I hate it. Look, if something is going to make you a badass, who cares how long it takes you to learn it?

Be empowered

My main point is this:

Near-term limitations are usually overblown. Focus more on empowering your team in the long term. Ask yourself, “which framework help my team be the most productive and happy over the course of the next couple years?”

The answer to that question is different for different organizations. My personal opinion is that for most organizations today it comes down to either Angular or Ember.

That does not mean, though, the other frameworks can’t be the answer. In certain situations, React, Backbone or another framework can make absolute sense. I just think right now, those use cases are the minority.

Why I chose Angular

So, why did I choose Angular over Ember?

  1. Fun to get started – Let’s be honest. There are large learning curves for both Angular and Ember when you want to build large applications. When you first start out, however, you can get up and running with a simple Angular app very quickly. I have found that this helps lower apprehensions some people may have for moving to a new technology.
  2. Framework Abstractions – I like dependency injection. I like fact that you can create your own Domain Specific Language (DSL) within HTML using Directives. I like the way you can group your components into modules. This is one of those things that just feelsright for me.
    • Note that Ember is working on a feature called HTMLBars which will have some Directive-like features.
  3. Flexibility – What is idiomatic Angular? No, seriously, what is it? I have no idea…and neither does anyone else. If you compare two large Angular projects from two different companies, they will almost certainly be very different because there are no well established standards for how the framework should be applied. This is in stark contrast to something like Ember where they live and die by well known standard best practices. The thing is, though, I have strong opinions of my own and I value the flexibility Angular gives me to define my directory structure and compose my app in the way that I want. You can of course do this with Ember, but you will definitely feel that you are going against the grain. Whereas with Angular it is totally OK for you to do things your own way.
  4. Focus on testing – Besides the ease of unit testing with dependency injection, the Angular team created two very good, robust testing frameworks in Testacular…I mean Karma…and Protractor.
    • Note that while traditionally Ember has been behind Angular on the testing front, they seem to be making improvements with their recent Ember CLI initative.
  5. Fantastic Community – I have gotten to know many prominent members of the Angular community the past year including several members of the core team and outside of SEO, we share many of the same thoughts for how web apps should be built. The Ember community is also very strong, but I just feel more of a connection to the Angular community.

Areas for Improvement

I don’t have time to go over everything in the list, but these include many of the common gripes people (including myself) have with Angular. Some of these items, like the Router, have good alternatives from the community (see the UI Router). I am currently working on the problem of Angular server side rendering with pancakes.js.

Even though I don’t think any of these issues are earth shattering, it would be nice if they were addressed someday…

Angular 2.0

I have good news and I have bad news.

Good news: Outside server rendering, every one of these issues should be resolved with the Angular 2.0 release that is due out later this year.

Bad news: In order to resolve these issues and make advances in several other areas, the Angular team has decided to rewrite AngularJS from the ground up. The 2.0 release will only support evergreen browsers and Angular 1.x components may not be able to integrate at all with 2.x components.

My organization is not that concerned about this issue, however, because:

  1. Assuming 2.x doesn’t come out until the end of this year we likely won’t think about upgrading until a full calendar year from now by which time the IE8 market share will almost certainly drop under 1%.
  2. Although 1.x components may not integration with 2.x components, you would still be able to use 1.x in some parts of your app and 2.x in other parts (side note: you should be building many small apps in Angular instead of one large one).
  3. I think there is a good chance that the Angular team or someone from the commuty will figure out a good upgrade path even though one isn’t clear right now (no evidence on this, just my gut feeling).


Here are some links to resources that you can use to learn more about Angular.



Third Party Libraries


Thank you!

Ref: http://jeffwhelpley.com/angularjs/


[Dev Tip] How to run Background Tasks in ASP.NET

A few years back Phil Haack wrote a great article on the dangers of recurring background tasks in ASP.NET. In it he points out a few gotchas that are SO common when folks try to do work in the background. Read it, but here’s a summary from his post.

  • An unhandled exception in a thread not associated with a request will take down the process.
  • If you run your site in a Web Farm, you could end up with multiple instances of your app that all attempt to run the same task at the same time.
  • The AppDomain your site runs in can go down for a number of reasons and take down your background task with it.

If you think you can just write a background task yourself, it’s likely you’ll get it wrong. I’m not impugning your skills, I’m just saying it’s subtle. Plus, why should you have to?

There’s LOT of great ways for you to do things in the background and a lot of libraries and choices available.

Some ASP.NET apps will be hosted in IIS in your data center and others will be hosted in the Azure cloud. The spectrum of usage is roughly this, in my opinion:

  • General: Hangfire (or similar similar open source libraries)
    • used for writing background tasks in your ASP.NET website
  • Cloud: Azure WebJobs 
    • A formal Azure feature used for offloading running of background tasks outside of your Website and scale the workload
  • Advanced: Azure Worker Role in a Cloud Service
    • scale the background processing workload independently of your Website and you need control over the machine

There’s lots of great articles and videos on how to use Azure WebJobs, and lots of documentation on how Worker Roles in scalable Azure Cloud Services work, but not a lot about how your hosted ASP.NET application and easily have a background service. Here’s a few.


As it says “WebBackgrounder is a proof-of-concept of a web-farm friendly background task manager meant to just work with a vanilla ASP.NET web application.” Its code hasn’t been touched in years, BUT theWebBackgrounder NuGet package has been downloaded almost a half-million times.

The goal of this project is to handle one task only, manage a recurring task on an interval in the background for a web app.

If your ASP.NET application just needs one background task to runs an a basic scheduled interval, than perhaps you just need the basics of WebBackgrounder.

using System;
using System.Threading;
using System.Threading.Tasks;
namespace WebBackgrounder.DemoWeb
    public class SampleJob : Job
        public SampleJob(TimeSpan interval, TimeSpan timeout)
            : base("Sample Job", interval, timeout)
        public override Task Execute()
            return new Task(() => Thread.Sleep(3000));


Somewhat in response to the need for WebBackgrounder, .NET 4.5.2 added QueueBackgroundWorkItem as a new API. It’s not just a “Task.Run,” it tries to be more:

QBWI schedules a task which can run in the background, independent of any request. This differs from a normal ThreadPool work item in that ASP.NET automatically keeps track of how many work items registered through this API are currently running, and the ASP.NET runtime will try to delay AppDomain shutdown until these work items have finished executing.

It can try to delay an AppDomain for as long as 90 seconds in order to allow your task to complete. If you can’t finish in 90 seconds, then you’ll need a different (and more robust, meaning, out of process) technique.

The API is pretty straightforward, taking  Func<CancellationToken, Task>. Here’s an example that kicks of a background work item from an MVC action:

public ActionResult SendEmail([Bind(Include = "Name,Email")] User user)
    if (ModelState.IsValid)
       HostingEnvironment.QueueBackgroundWorkItem(ct => SendMailAsync(user.Email));
       return RedirectToAction("Index", "Home");
    return View(user);


FluentScheduler is a more sophisticated and complex scheduler that features a (you guessed it) fluent interface. You have really explicit control over when your tasks run.

using FluentScheduler;
public class MyRegistry : Registry
    public MyRegistry()
        // Schedule an ITask to run at an interval
        // Schedule a simple task to run at a specific time
        Schedule(() => Console.WriteLine("Timed Task - Will run every day at 9:15pm: " + DateTime.Now)).ToRunEvery(1).Days().At(21, 15);
        // Schedule a more complex action to run immediately and on an monthly interval
        Schedule(() =>
            Console.WriteLine("Complex Action Task Starts: " + DateTime.Now);
            Console.WriteLine("Complex Action Task Ends: " + DateTime.Now);
        }).ToRunNow().AndEvery(1).Months().OnTheFirst(DayOfWeek.Monday).At(3, 0);

FluentScheduler also embraces IoC and can easily plug into your favorite Dependency Injection tool of choice by just implementing their ITaskFactory interface.


Quartz.NET is a .NET port of the popular Java job scheduling framework of the (almost) same name. It’s very actively developed. Quartz has an IJob interface with just one method, Execute, to implement.

using Quartz;
using Quartz.Impl;
using System;
namespace ScheduledTaskExample.ScheduledTasks
    public class JobScheduler
        public static void Start()
            IScheduler scheduler = StdSchedulerFactory.GetDefaultScheduler();
            IJobDetail job = JobBuilder.Create<MyJob>().Build();
            ITrigger trigger = TriggerBuilder.Create()
                  (s =>
                    .StartingDailyAt(TimeOfDay.HourAndMinuteOfDay(0, 0))
            scheduler.ScheduleJob(job, trigger);

Then, inside your Application_Start, you call JobScheduler.Start(). There’s a great getting started article on Quartz at Mikesdotnetting you should check out.


And last but definitely not least, the most polished (IMHO) of the group, Hangfire by @odinserj. It’s afantastic framework for background jobs in ASP.NET. It’s even optionally backed by Redis, SQL Server, SQL Azure, MSMQ, or RabbitMQ for reliability.

The Hangfire documentation is amazing, really. Every open source project’s document should be this polished. Heck, ASP.NET’s documentation should be this good.

The best feature from Hangfire is its built in /hangfire dashboard that shows you all your scheduled, processing, succeeded and failed jobs. It’s really a nice polished addition.


You can enqueue “fire and forget” jobs easily and they are backed by persistent queues:

BackgroundJob.Enqueue(() => Console.WriteLine("Fire-and-forget"));

You can delay them…

BackgroundJob.Schedule(() => Console.WriteLine("Delayed"), TimeSpan.FromDays(1));

Or great very sophisticated CRON style recurrent tasks:

RecurringJob.AddOrUpdate(() => Console.Write("Recurring"), Cron.Daily);

Hangfire is just a joy.

Check out the Hangfire Highlighter Tutorial for a sophisticated but easy to follow real-world example.

There’s a rich ecosystem out there ready to help you with your background tasks. All these libraries are excellent, are open source, and are available as NuGet Packages.

Did I miss your favorite? Sound off in the comments!

Ref: http://www.hanselman.com/blog/CategoryView.aspx?category=NuGetPOW

[Discovery] Các nhà nghiên cứu đã khám phá ra loại protein có thể ngăn chặn sự phát tác của virus HIV và Ebola

virus_3d. ​Mới đây, các nhà khoa học đã bất ngờ tìm thấy một nhóm protein có khả năng ngăn chặn quá trình xâm nhập của HIV type 1 (HIV-1) vào những tế bào mới. Một điều thú vị khác là loại protein này còn có thể ức chế sự phát tán của những chủng virus khác bao gồm cả virus Ebola. Trước tình hình Ebola có thể lây lan thành một đại dịch trên toàn cầu, phát hiện trên không chỉ giúp các nhà khoa học có thêm hiểu biết về sự tương tác giữa virus và protein trong cơ thể người mà còn góp phần mở đường sứ mạng tìm kiếm phương pháp ngăn chặn sự lây lan của các đại dịch nguy hiểm trong tương lai không xa.

Về cơ bản, virus không có khả năng tự tái tạo nên chúng phải đi chiếm một tế bào chủ khác để duy trì sự sống. Để xâm nhập vào bên trong tế bào chủ, HIV hoặc các chủng virus suy giảm miễn dịch khác cần phải liên kết với các thụ thể tồn tại bên trong tế bào mục tiêu. Tiếp theo đó là nhiều sự kiện diễn ra nhằm phục vụ quá trình xâm nhập của HIV. Sau khi đã xâm nhập thành công virus sẽ chuyển đổi tế bào thành một nhà máy có nhiệm vụ tiếp tục sản sinh thêm virus.

Các nghiên cứu gần đây đã phát hiện ra một nhóm protein mang tên TIM protein. Đây là loại protein có vai trò quan trọng để tạo điều kiện cho sự xâm nhập của nhiều loại virus như Ebola, siêu vi Tây sông Nile (West Nile) và cả virus gây bệnh sốt xuất huyết. Một cách hết sức bất ngờ, nhóm các nhà nghiên cứu tại Đại học Missouri đã phát hiện thêm rằng các protein trên không chỉ có khả năng ngăn chặn quá trình xâm nhập của HIV-1 vào tế bào chủ mà còn ngăn chặn sự phát tán của virus.

Trong nhiều thí nghiệm, các nhà khoa học đã nghiên cứu sự tương tác giữa HIV-1 và protein TIMbằng các biện pháp phân tử, hóa sinh và các kỹ thuật quan sát dưới kính hiển vi. Cuối cùng, các nhà nghiên cứu đã phát hiện rằng khi HIV-1 bắt đầu tạo mầm mống hoặc chuẩn bị phát tán ra khỏi tế bào chủ, protein TIM sẽ gắn kết vào cấu trúc của virus và trói buộc nó vào màn tế bào. Đây là cấu trúc trung gian được hình thành nhờ vào sự tương tác với một loại chất béo mang tên phosphatidylserine (PS) được tìm thấy trong màng tế bào và nên ngoài bề mặt virus.

Thông thường, PS sẽ được vận chuyển vào bên trong tế bào, nhưng sự lây nhiễm virus làm nó bị loại trở lại bên ngoài. Điều này có nghĩa là cả PS và TIM đều tồn tại ở cả tế bào lẫn trên bề mặt virus. Nói một cách nôm na, PS và TIM đã cùng nhau giúp buộc chặt virus ở bên ngoài màng tế bào khiến nó không thể nào xâm nhập và tiếp tục lây lan được nữa.

Mặt khác, điều thú vị ở đây là nhóm đã khám phá rằng protein TIM cũng có khả năng ức chế sự lây nhiễm của những chủng virus khác, bao gồm cả những loại virus cơ hội như HIV và Ebola. Tuy nhiên, cho tới hiện tại, các nhà nghiên cứu vẫn chưa xác định được tương tác giữa protein TIM và virus là nhân tố tích cực hay tiêu cực. Tuy nhiên, người dẫn đầu nhóm nghiên cứu cho rằng phát hiện này đã gia tăng sự hiểu biết của các nhà khoa học về sự tương tác giữa virus với cơ thể người, qua đó mở đường cho quá trình đề xuất liệu pháp chống virus trong tương lai.

Tham khảo: Đại học Missouri, PNAS, SD, IFS

[Discovery] Google phát triển hệ thống Knowledge Vault nhằm lưu trữ toàn bộ tri thức của nhân loại


Theo báo cáo mới nhất, Google đang xây dựng một hệ thống cơ sở dữ liệu thế hệ mới mang tênKnowledge Vault với khả năng thu thập, phân loại và lưu trữ toàn bộ những sự kiện có thật của con người trong quá khứ, hiện tại và liên tục tự cập nhật trong tương lai. Hãng tuyên bố rằng đây là cơ sở dữ liệu lớn nhất trong lịch sử nhân loại và có thể hoạt động mà không cần sự trợ giúp của con người.

Về cơ bản, Knowledge Vault là một hệ thống lưu trữ dữ liệu có thể dùng các thuật toán thông minh để tự động thu thập và hợp nhất thông tin từ khắp nơi trên internet và lưu trữ tại một nơi duy nhất. Thông tin bao gồm tất cả những sự việc có thật trên thế giới, con người và sự vật có hiện diện trong sự việc đó. Các chuyên gia gọi đây là một dạng “nền tảng tri thức”, một hệ thống mà cả con người lẫn máy móc có thể truy cập vào cơ sở dư dữ liệu của nó để khai thác thông tin.

Khi hoàn tất, người dùng có thể truy vấn kiến thức trực tiếp đến Knowledge Vault thông qua bộ máy tìm kiếm Google. Hoặc cách khác là sử dụng smartphone, các trợ lý kỹ thuật số cá nhân hoặc thậm chí là robot để giúp người dùng tìm kiếm thông tin. Trên thực tế, đây là dự án được xây dựng trên nền tảng dữ liệu đám đông sẵn có của Google mang tên Knowledge Graph.

Cho tới thời điểm hiện tại, Knowledge Graph đã liệt kê được khoảng 1,6 tỷ sự kiện của con người, 271 triệu trong số đó là vô cùng chính xác và Google tuyên bố rằng hơn 90% là đúng sự thật. Tuy nhiên, quá trình thu thập và nhập dữ liệu cho Knowledge Graph được thực hiện bởi con người nên mất khá nhiều thời gian, do đó, Google quyết định sẽ tự động hóa quá trình trên với tham vọng thâu tóm được toàn bộ tri thức của nhân loại. Khi đó, những dữ liệu thô mới được chuyển thành dạng tri thức khả dụng.

Theo giới phân tích, đây là một sáng kiến góp phần thúc đẩy sự phát triển của công nghệ thông tin, tạo ra một cơ sở dữ liệu thuần khiết, tính khả dụng cao nhằm cải thiện cách thức con người giao tiếp với máy móc và cơ sở dữ liệu trong tương lai. Về lý thuyết, mục đích trên tương tự như nền tảng cơ sở dữ liệu của các hãng Facebook, Amazon, Microsoft hay IBM. Một ứng dụng khả thi nhất mà chúng ta có thể thấy được là phục vụ cho các trợ lý ảo cá nhân. Khi đó thì Siri, Cortana hay Google Now có thể thông minh hơn và nhanh hơn rất nhiều so với hiện tại.

Khối lượng kiến thức của Knowledge Vault có thể giúp con người và máy móc tương tác với nhau tốt hơn rất nhiều. Khi đó, máy móc có thể hiểu được con người hoặc thậm chí là đưa ra các dự đoán về tương lai. Tuy nhiên, các chuyên gia cũng lo ngại mức độ rủi ro về bảo mật của dự án này. Hay nói cách khác, Knowledge Vault không cần biết bạn là ai, có quan trọng hay nổi tiếng không, việc nó làm chỉ đơn giản là thu thập tất cả thông tin về bạn và nếu có thể gây hại cho người dùng nếu thông tin bị sử dụng với mục đích xấu.

Tham khảo Newscientist, Discovery, BGR

[Infographic] Lịch sử của những món ăn được yêu thích

header-lich su cua nhung mon an duoc ua thich.

Sự phát triển của kinh tế, xã hội và khoa học kỹ thuật trên thế giới khiến toàn cầu hóa ngày càng diễn ra một cách mạnh mẽ. Ngày nay, chúng ta có thể tiêu dùng những hàng hóa, dịch vụ của hầu hết mọi nơi trên thế giới. Chắc hẳn nhiều món ăn bạn mê mẩn xuất phát từ những nước khác.

Tuy nhiên, bạn đã biết được rõ nguồn gốc món ăn mà bạn yêu thích? Trong quá trình đi qua nhiều nước, các món ăn đã được thay đổi và phát triển như ngày nay. Tìm hiểu lịch sử những món ăn yêu thích trong infographic dưới đây.

[Submit] lich su cua nhung mon an ua thich.

Nguồn: Visual.ly

[Infographic] Lịch sử của công cụ tìm kiếm


Sự ra đời của Internet đem lại cho con người một kho dữ liệu khổng lồ ở nhiều lĩnh vực. Dù ở bất kì nơi nào trên trái đất, chỉ với chiếc máy tính nối mạng, chúng ta đều có thể truy cập vào những dữ liệu đó. Tuy nhiên, mọi chuyện trước đây không hề dễ dàng như vậy.

Đã có rất nhiều các công cụ tìm kiếm ra đời, trải qua cạnh tranh khắc nghiệt và những cải tiến khoa học mà ngày nay chúng ta mới có những công cụ tuyệt với như Google, YouTube. Cùng tìm hiểuInfographic dưới đây để có thêm thông tin về lịch sử phát triển của các công cụ tìm kiếm.

[Submit] lich su cua cong cu tim kiem.

Nguồn: seo.com

[Startup] Airbnb: làm thế nào một startup gần phá sản trở thành “đế chế cho thuê nhà online”?

Gần đây, Airbnb bắt đầu có những động thái tiến sâu vào thị trường Việt Nam, đơn cử như việc có đến hàng trăm chỗ cho thuê hoặc “ở ké” trên địa bàn Hồ Chí Minh và Hà Nội. Bên cạnh đó, việc Airbnb đang bắt đầu tuyển dụng nhân lực tại Việt Nam càng chứng tỏ ý định tiến vào Việt Nam một cách nghiêm túc của “đế chế cho thuê nhà online” này.

Nhưng có lẽ ít ai biết được, để có được ngày hôm nay Airbnb đã phải trải qua cả một chặng đường dài khó khăn, vất vả, có những giai đoạn tưởng chừng như phá sản. Vậy làm thế nào Airbnb từ một startup không tăng trưởng, lỗ dài ngày chỉ với doanh thu lẹt đẹt 200 USD/1 tuần có thể xoay chuyển thành một doanh nghiệp có doanh thu hàng tỷ USD? Hãy xem những bài học rút ra từ Joe Gebbia, đồng sáng lập Airbnb để có câu trả lời.


Năm 2009, Airbnb đã gần như phá sản. Như nhiều startup khác, họ thành lập công ty nhưng chẳng mấy ai để ý. Doanh thu của công ty cứ đì đẹt ở mức 200 đô la một tuần, chia cho 3 thành viên sáng lập tại San Francisco, tức là lỗ dài và không hề tăng trưởng.

Theo lời Joe Gebbia – đồng sáng lập của Airbnb thừa nhận thì đồ thị tăng trưởng của công ty là một đường thẳng nằm ngang, trong khi ai cũng biết là các nhà đầu tư mạo hiểm luôn thích tìm những công ty có tăng trưởng đi lên ấn tượng. Và họ đã buộc phải dốc hết túi tiền.

Không phải lúc nào giải quyết bằng máy móc cũng tốt

Khi đó, Airbnb đang còn trong vườn ươm . Một buổi chiều, cả nhóm sáng lập cùng với Paul Graham xem xét các kết quả tìm kiếm cho thành phố New York trên Airbnb để cố gắng tìm ra điều gì chưa được và tại sao công ty không phát triển. Sau đó Gebbia nhận ra:

Chúng tôi đã nhìn ra vấn đề. Có một điểm chung trong cả 40 kết quả tìm kiếm, đó là hình ảnh quá tệ. Toàn là ảnh xấu. Mọi người chỉ dùng camera điện thoại để chụp ảnh hoặc lấy ảnh ở trên mạng. Không ngạc nhiên khi chẳng có ai muốn đặt phòng vì người ta thậm chí còn không nhìn ra nổi họ đang trả tiền cho cái gì.

Graham đã đưa ra một giải pháp rất thủ công và không “công nghệ” tí nào: đi tới New York, mượn máy ảnh và cùng với các đối tác chụp những tấm hình thật đẹp với độ phân giải cao để thay cho những tấm hình nghiệp dư xấu xí. Nhóm 3 người họ đã bắt chuyến bay sớm nhất để đến New York thực hiện nhiệm vụ. Vào thời điểm đó không có các số liệu cụ thể nào ủng hộ quyết định này. Họ chỉ đơn giản là cứ làm thôi. Kết quả thu được sau một tuần là: những bức hình đẹp đã làm tăng gấp đôi doanh thu lên 400 đô la một tuần. Đó là cải thiện về mặt tài chính đầu tiên của công ty sau 8 tháng. Và họ biết rằng họ đã đi đúng hướng.

Đó là một bước ngoặt đối với công ty. Gebbia cho biết rằng, lúc đầu, mọi người trong nhóm đều tin rằng cần phải làm mọi thứ theo kiểu rất “công nghiệp hiện đại”. Chỉ đến khi họ tự cho phép mình thử nghiệm những phương pháp “thủ công” thì công ty mới thoát khỏi chặng đường khó khăn.


Ở thung lũng Silicon, chúng ta có một thiên kiến rằng mọi vấn đề phải được giải quyết theo kiểu công nghệ hiện đại bởi vì đó là nét đẹp của lập trình. Bằng một đoạn mã lệnh, ta có thể giải một hay 10 ngàn thậm chí 10 triệu bài toán tương tự nhau. Trong năm đầu kinh doanh, chúng tôi dán mắt vào màn hình máy tính giải quyết vấn đề bằng các dòng lệnh. Đó là một dạng giáo điều vô căn cứ. Chỉ đến khi gặp Paul Graham tại Y Combinator, về căn bản, đó là lần đầu tiên chúng tôi thấy mình được phép làm việc một cách thủ công, và tôi không bao giờ quên thời điểm đó, thời điểm đã đưa công ty sang một trang mới.

Tại sao phải làm người bình thường khi ban có thể tiên phong?

Dù Airbnb được vận hành chủ yếu dựa trên các số liệu nhưng họ không để các con số này thao túng mình. Thay vì phát triển theo cách phản ứng với các thang đo, các dữ liệu, họ thường bắt đầu với một giả thiết sáng tạo, đưa vào một thay đổi, xem xét ảnh hưởng tới công ty như thế nào rồi lặp lại quá trình này.


Gebbia cho hay:

Tôi chẳng biết dữ liệu có ích gì nếu chúng ta không có một phương pháp tốt để kiểm tra lại. Dữ liệu hoàn toàn có thể sai lệch. Cách chúng tôi làm việc đó là khi chúng tôi có một ý tưởng chúng tôi sẽ thực hiện ngay cả khi chúng chưa khả thi trong việc mở rộng. Cách thức này đã được đưa vào văn hóa làm việc của công ty. Bạn sẽ làm một tên cướp biển, dấn thân đi thám hiểm và tìm kiếm của cải rồi quay về kể lại những câu chuyện của mình.

Từng thành viên trong nhóm tại Airbnb đánh cược với những tính năng mới, sau đó tính toán xem có những thành quả ý nghĩa nào từ đó không. Nếu có, họ sẽ điều thêm cướp biển về hướng đó. Cấu trúc này khuyến khích nhân viên mạo hiểm có tính toán và năng suất trên danh nghĩa công ty để từ đó tiến tới sự phát triển những tính năng to lớn hơn. Điều này cho phép Airbnb có thể tiến rất nhanh và liên tục tìm ra những cơ hội mới.

Gebbia giải thích kĩ hơn ý tưởng này như sau:

Chúng tôi cố gắng xây dựng một môi trường làm việc mà trong đó, mọi người ngay khi nhìn thấy dấu hiệu le lói của một thứ gì đó hy vọng, họ sẽ quăng thuốc nổ vào để làm vỡ bung ra thành một thứ gì khác to lớn hơn mà chưa ai từng có thể nghĩ tới.


Mỗi người thiết kế cần phải là một người dùng

Kinh nghiệm của Gebbia về nâng cấp hình ảnh đã chứng tỏ rằng các dòng mã lệnh không thể giải quyết tất cả các vấn đề khách hàng gặp phải. Dù máy tính và các phần mềm rất mạnh mẽ chúng cũng có những giới hạn nhất định. Các nhà khởi nghiệp ở thung lũng Silicon có xu hướng cảm thấy thoải mái với vai trò làm “anh hùng bàn phím” của mình. Tuy nhiên, ra ngoài gặp gỡ khách hàng hầu như luôn là cách tốt nhất để đưa ra những giải pháp thông minh cho những vấn đề của họ.

Gebbia cho rằng những bài học đầu tiên ở trường thiết kế đã định hình tư duy của anh về phát triển khách hàng:

Nếu đang làm một thiết bị y tế, chúng tôi cũng sẽ đi ra ngoài thế giới. Chúng tôi sẽ nói chuyện với các nhà đầu tư, với tất cả những người dùng sản phẩm y tế, bác sĩ, y tá và bệnh nhân và chúng tôi sẽ có những giây phút giác ngộ khi nằm xuống giường bệnh, được khám bởi chính thiết bị y tế đó và biết được cảm giác khó chịu của bệnh nhân là như thế nào. Từ đó sẽ tìm ra cách cải thiện thiết bị tốt hơn.

Điều này đã thôi thúc Gebbia đưa “trải nghiệm của bệnh nhân” thành giá trị cốt lõi của nhóm thiết kế. Tất cả các thành viên mới sẽ cảm nhận ngay lập tức khát khao “được trở thành bệnh nhân” khi bước vào nhóm.

Mọi người có một hoặc hai tuần đầu tiên tham quan công ty và sau đó ghi chép lại những gì mắt thấy tai nghe. Chúng tôi đưa cho họ một bộ câu hỏi để trả lời và sau đó chia sẻ lại cho toàn công ty. Một điều tối quan trọng đó là tất cả mọi người trong công ty cần biết chúng tôi rất tin tưởng vào giá trị cốt lõi này, và chúng tôi sẵn sàng trả lương cho mọi người để dành một tuần đầu tham quan.


Biến sản phẩm trở thành “con đẻ” của tất cả mọi thành viên trong công ty

Là một phần của quá trình đào tạo nhân viên mới của Airbnb, công ty khuyến khích mọi người đóng góp tính năng mới ngay từ ngày đầu tiên. Điều này giúp học trở nên vững vàng và chứng tỏ rằng các ý tưởng lớn có thể nảy ra từ bất cứ ai. Phương pháp tiếp cận này có thể đem lại những kết quả bất ngờ.

Ví dụ, có lần một nhà thiết kế của Airbnb được giao nhiệm vụ nho nhỏ là đánh giá lại chức năng đánh dấu bằng biểu tượng ngôi sao. Ở sản phẩm nguyên bản của Airbnb, người dùng có thể “đánh dấu sao” để thêm một danh mục nào đó vào danh sách mong muốn (wish list) của mình – một chức năng cơ bản. Gebbia nhớ lại:

Nhà thiết kế mới của chúng tôi quay lại và nói “Tôi biết rồi!”. Tôi hỏi lại “biết rồi” là sao, anh mới dành có một ngày xem xét thôi mà? Anh ta tiếp tục: “Tôi nghĩ hình ngôi sao là thứ gì đó đem lại cảm giác khô khan như một công cụ thông thường thôi. Mà dịch vụ của chúng cần đem lại cảm giác đầy khát khao. Sao chúng ta không xem xét lại cái này? Tôi sẽ đổi hình ngôi sao thành hình trái tim. “Tôi “ồ” lên một tiếng và bảo “được”. Rất thú vị, và chúng tôi làm. Khi thay đổi, chúng tôi đưa vào cả đoạn mã để theo dõi những thay đổi của người dùng.

Đúng như mong đợi, một thay đổi đơn giản từ hình ngôi sao sang trái tim đã làm tăng hơn 30% doanh số. Tóm lại, cứ để mọi người làm cướp biển, đi tìm và mang về những thứ mới mẻ.

Lời kết

Chúng ta thường phải đi rất nhanh khi xây dựng sản phẩm ở giai đoạn startup. Rất vất vả vì ta cần phải đưa được ra sản phẩm. Gebbia cố gắng cân bằng thực tế này với sự cần thiết phải đổi mới tư duy bằng cách liên tục thúc ép nhóm của mình nghĩ rộng hơn.

Mỗi khi có ai đưa đến cho tôi một thứ gì đó, bản năng đầu tiên của tôi khi xem xét nó là phải nghĩ rộng hơn. Đó cũng là một lời khuyên theo bản năng của tôi. Nghĩ rộng hơn. Bất kể nó là cái gì, cứ tách ra từng mảnh và xem chuyện gì xảy ra. Sau đó quay lại gặp tôi khi bạn đã nghĩ về nó hàng trăm lần, cho tôi biết nó trông như thế nào.

(Xem thêm: Aothun.vn: Vượt qua nợ nần và mong muốn đóng góp lại cho cộng đồng)

(Biên tập bởi Quyên Quyên)

Bình luận trên Facebook