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

[Dev Tip] WSDL vs MEX, knockout or tie?

When teaching WCF I am always asked about the difference between getting the service’s metadata by using the WSDL’s http get url, and getting the metadata by calling the MEX endpoint.

To answer that question we first need to understand the different parts of the configuration that affect metadata creation.

The ServiceMetadata behavior

This behavior controls whether metadata is created for the service. When this behavior is used, the service is scanned, and metadata is created for the service’s contracts (a list of operations and types exposed by the service).

If the behavior is not used, no metadata will be created for the service, and you will not be able to create MEX endpoints.

The ServiceMetadata’s httpGetEnabled flag

This flag defines whether the metadata will be accessible by an http get request. If this attribute is set to true, then a default url will be created for the metadata (usually the service’s address with the suffix of  ‘?wsdl’). The url will lead you to a WSDL file containing the description of the service operations, but without the description of the data contracts – these files are accessible by different urls, usually the service’s url with the suffix of ‘?xsd=xsdN’. The list of these urls are pointed out from the WSDL file.

If you do not set this attribute to true, you will not be able to access the metadata using http get requests. If you prefer using https for the get requests, you can use the httpsGetEnabled attribute instead of the httpGetEnabled.

There are several other settings for the get options – you can read more about them on MSDN.

The MEX endpoint

MEX endpoints are special endpoints that allow clients to receive the service’s metadata by using SOAP messages instead of http get requests. You can create MEX endpoint that can be accessed through http, https, tcp, and even named pipes.

The response that you will receive when calling a MEX endpoint’s GetMetadata operation will include the content of the WSDL and all the XSD files that are linked to it.

So what exactly is the difference between MEX and WSDL?

There is no difference!

MEX and WSDL both output the same thing – a web service description language (WSDL) document, only MEX does it by getting a SOAP message over some transport (http, tcp, named pipes) and returning one message with all the parts, while the WSDL urls use http get requests and require sending several requests to get all the parts.

Don’t believe me?

The following diff diagram was produced by comparing the output of a MEX call to the output of the aggregated results gathered by calling all the WSDL related urls using http get:


As you can see, there are only several sections that are different between the files (marked in red and yellow), while most of the content is identical. Let’s look at one of these parts:


The red lines come from the MEX result, and the yellow lines from the WSDL file. The difference is because when using WSDL files, the rest of the XSD files are linked by using the <xsd:import> tag with the schemaLocation attribute. Since the MEX response includes all the XSD content in it, the import tag doesn’t include the location attribute.

As for the other different sections – they are different because the MEX response wraps each WSDL/XSD part with an xml element that does not appear in the aggregated files. These elements are part of the MEX standard declared by the W3C – surprise surprise, MEX is a W3C standard, it’s not a Microsoft proprietary spec.

So they are the same, still, which one to use?

In most cases there is no need for MEX endpoint – using WSDLs with http get is usually enough.

The “Add Service Reference” option in Visual Studio 2010 will work for both options. The same goes for the svcutil command line tool.

So when would I use MEX?

  1. If you want to make as less calls as possible to your service in order to get its metadata (one call instead of several).
  2. If you don’t want to use HTTP to get the metadata, but prefer using TCP or named pipes (not so common).
  3. If you want people to ask you why you declared a MEX endpoint.

So is it a knockout or a tie? I say tie.

[Dev Tip] Exposing WCF services with SOAP and REST endpoints

Simultaneously exposing a WCF service with both SOAP and REST endpoints is not as difficult as it may sound. It requires just a few updates to the codebase and configuration. But first, let’s start from the beginning.

This post assumes that you have a WCF service (new or existing) that is only providing a SOAP endpoint. I’m making this assumption because that is the default endpoint for any new WCF service that you create from Visual Studio. The goal is to reconfigure the service to expose the additional REST endpoint.

Another thing to consider is that how you call a service is not always the same thing as to what (format) you expect from it. In other words, if you are downloading a resource from a RESTful URL, then the resource being returned can still be any format such as XML or JSON (further assuming that that we’re talking about character data). However, nowadays, many RESTful services do in fact return JSON data as the default format, so we’ll make assumption in this post as well: that the REST endpoint will return JSON payload, while the SOAP endpoint returns an XML payload.

Let’s get to it.

First, we need to configure the REST endpoint:

  1. Open your WCF project/solution with Visual Studio.
  2. Open the application configuration file (app.config or web.config).
  3. Locate the appropriate service element (under configuration/system.ServiceModel/services).
    Note that the existence of an endpoint element which describes the SOAP endpoint.
  4. Add a new endpoint element under the service element that is similar to the SOAP endpoint; a simple copy/paste of the existing endpoint element should suffice.
  5. Ensure that address attribute for both endpoints are not the same because those values map to a part of the URL that exposes those endpoints.
    For example, provide “soap” and “rest” as values for the address attribute.
  6. Ensure that the newly created REST endpoint has a binding attribute value of webHttpBinding.
    Note that if you copied and pasted this element from the existing one that the binding attribute value will be basicHttpBinding (or some other type of binding).Your endpoint configuration should look similar to:
    <service name="SoapRestEnabledService.Service1">
    <!-- Service Endpoints -->
    <!-- Unless fully qualified, address is relative to base address supplied above -->
    <endpoint address="soap" binding="basicHttpBinding" contract="SoapRestEnabledService.IService1">
    <dns value="localhost" />
    <endpoint address="rest" binding="webHttpBinding" contract="SoapRestEnabledService.IService1" behaviorConfiguration="restEndpointBehavior">
    <dns value="localhost" />
    <!-- Metadata Endpoints -->
    <!-- The Metadata Exchange endpoint is used by the service to describe itself to clients. -->
    <!-- This endpoint does not use a secure binding and should be secured or removed before deployment -->
    <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />

Because we are assuming that the payload format for the REST endpoint should be JSON, we need to configure the endpoint to do so. To do this, we add an endpoint behavior.

  1. In the configuration file, locate the endpointBehaviors element (under configuration/system.serviceModel/behaviors).
  2. Add a new behavior element, and provide a name attribute value such as “restEndpointBehavior”.
  3. Add a new webHttp element in the new behavior.
    From here, we can either indicate that the payload is formatted automatically or specifically.
    To format it automatically, ensure that the automaticFormatSelectionEnabled is set to True.
    To format it specifically (to JSON), ensure that the defaultOutgoingResponseFormat is set to Json.Your new endpoint should look similar to:
      <behavior name="restBehavior">
        <webHttp helpEnabled="true" defaultOutgoingResponseFormat="Json" />
  4. Now, associate the endpoint behavior to the endpoint itself by adding/modifying the behaviorConfiguration attribute on the endpoint (see the first xml configuration above).

The service is now configure to expose the service as both SOAP and REST endpoints.

But wait, we’re not done. We also have to enable the service methods for REST:

  1. Add a Reference to System.ServiceModel.Web to the project.
  2. Add WebGet or WebInvoke attributes to each method for the service. In some cases, such as using WebInvoke, you will need to use UriTemplates to better control the URL.Your service (interface) should now look similar to:
    public interface IService1
        string GetName();
        [WebInvoke(UriTemplate = "getdata/{value}")]
        string GetData(string value);
        CompositeType GetDataUsingDataContract(CompositeType composite);

Well, that’s about the brunt of what needs to be changed.

[Discovery] Các loại ống kính máy ảnh, công dụng và ứng dụng của ống tele trong nhiếp ảnh

Ống kính tele là một công cụ tuyệt vời giúp người cầm máy tiến gần đến chủ thể ngay cả khi không thể. Thiết bị thích hợp cho cả ảnh chân dung cũng như ảnh phong cảnh, thiên nhiên hoang dã. Tuy nhiên, để có những shot hình đẹp, người dùng cũng nên chú trọng đầu tư phụ kiện nhằm giảm thiểu nhòe hình do rung máy.

Ống normal và tele

Trong lịch sử nhiếp ảnh, tiêu cự 50mm được chọn là tiêu cự chuẩn và thường được gọi là tiêu cự “normal” cho định dạng phim 35mm. Những ống kính tiêu cự 50mm vì thế cũng được gọi là ống normal nhằm phân biệt với các ống kính zoom, tele khác. Sở dĩ 50mm được xem là tiêu cự chuẩn vì khi ngắm chụp qua ống kính tiêu cự này, hình ảnh không hề bị hiện tượng méo hình hay bị thay đổi kích thước so với thực tế. Ống kính có tiêu cự 50mm khi gắn trên máy phim 35mm sẽ cho trường nhìn, góc nhìn tương đương với mắt thường của con người. Nếu nhân tiêu cự này lên 4 lần, ta sẽ có tiêu cự 200mm và có nghĩa là hình ảnh thực tế sẽ được phóng đại lên gấp 4 lần so với thực tế.

Ảnh chụp sử dụng EOS 40D, ống Canon EF 28-135mm/f3.5-5.6 IS USM tại tiêu cự zoom tối đa.

Ảnh chụp sử dụng EOS 40D, ống Canon EF 28-135mm/f3.5-5.6 IS USM tại tiêu cự zoom tối đa.

Tuy vậy, người dùng cần chú ý để tránh nhầm lẫn giữa ống kính zoom và ống kính tele vì ống kính tete nói một cách ngắn gọn là những ống có góc nhìn rất hẹp và có chiều dài vật lý ngắn hơn nhiều so với chiều dài tiêu cự mà nó hỗ trợ. Có những model ống tele có tiêu cự cố định và chỉ có thể lấy nét trong một khoảng cách nhất định. Song, cũng có những loại ống kính tele hỗ trợ thay đổi chiều dài tiêu cự thường được gọi là telephoto zoom lens. Sở dĩ ống kính telephoto có thể zoom là do bên trong mỗi sản phẩm được thiết kế nhiều nhóm thấu kính rất phức tạp hỗ trợ lấy nét, nhóm có thể dịch chuyển để điều chỉnh điểm hội tụ khi zoom. Ngoài ra còn có khá nhiều khía cạnh kỹ thuật khác mà khi mô tả cần đến rất nhiều giấy mực. Xét về ngoại hình, hiện tại, thị trường có những ống kính tele khá gọn nhẹ, có thể dễ dàng di chuyển và mang theo bên mình – song cũng có những model rất lớn và nặng tùy theo cấu trúc thiết kế và chức năng của sản phẩm.

Thị trường hiện tại có khá nhiều loại ống telephoto zoom lens, song được đánh giá cao nhất vẫn là những đại diện như Nikon AF-S Nikkor 70-200mm/f2.8G ED VR II, Nikon AF-S VR Zoom Nikkor 70-300mm/f4.5-5.6G IF-ED, Sigma 120-400mm/F4.5-5.6 DG APO OS HSM, Canon EF 70-200mm/f4L IS USM, Canon EF 70-300mm/f4-5.6L IS USM, Tamron 18-270mm Di II VC PZD.

Nikkor 70-300mm/f4.5-5.6G IF-ED VR là một trong những lựa chọn tốt trong tầm giá 10 triệu đồng

Nikkor 70-300mm/f4.5-5.6G IF-ED VR là một trong những lựa chọn tốt trong tầm giá 10 triệu đồng

Ống kính zoom

Ống kính zoom là một loại ống kính có khả năng phóng đại một phần hình ảnh thành một hình ảnh lớn hơn. Về cấu tạo, ống kính zoom được cấu tạo gồm nhiều bộ thấu kính ghép lại với nhau và có khả năng thay đổi tiêu cự (để phóng đại hình ảnh) – khác biệt hoàn toàn với các loại ống fix vốn chỉ hỗ trợ một tiêu cự cố định. Hầu hết các máy ảnh PnS ngày nay đều được trang bị ống kính zoom với nút chức năng tương ứng để tùy chỉnh độ dài tiêu cự mong muốn. Máy ảnh ống kính rời (DSLR) cũng có thể kết hợp sử dụng với các ống kính zoom tương thích. Tuy nhiên, khác với PnS, để thay đổi chiều dài tiêu cự của những ống kính này, người dùng phải xoay chuyển vòng cao su trên thân ống kính.

Những ống kính có khả năng zoom thường được phân biệt bằng 2 chỉ số tiêu cự (đơn vị tính bằng milimet) in trên thân ống hoặc trong tên gọi sản phẩm. Ví dụ như Canon EF-S 55-250mm/f4-5.6 IS, Nikkor AF-S 70-300mmf4.5-5.6G VR… Ngoài việc ứng dụng trong chụp ảnh, ống kính zoom còn được dùng như một viễn vọng kính có độ phóng đại thay đổi được, hay dùng để phát một tia laser có công suất trên một đơn vị diện tích có thể thay đổi.

Ống zoom góc rộng (wide-angle lens)

Theo định nghĩa trong nhiếp ảnh và kỹ thuật điện ảnh, ống kính góc rộng (wide-angle lens) là những ống kính có chiều dài tiêu cự nhỏ hơn nhiều so với tiêu cự chuẩn 50mm của định dạng phim 35mm. Ống kính góc rộng thường có góc nhìn rất rộng nên có thể bao quát cả một không gian lớn chỉ trong một bức ảnh. Chính vì điều này mà ống kính góc rộng rất thích hợp cho chụp ảnh nội thất, ảnh phong cảnh – khi người chụp không thể di chuyển xa hơn khỏi khung cảnh cần chụp. Ống kính góc rộng còn được dùng để nhấn mạnh sự khác biệt về khoảng cách giữa chủ thể với tiền cảnh và hậu cảnh – vì với loại lens này, đối tượng chụp càng gần máy sẽ có kích thước càng lớn và ngược lại. Trong định dạng phim 35mm, ống kính góc rộng thường có tiêu cự nằm trong khoảng từ 24mm đến 35mm. Những ống kính có chiều dài tiêu cự nhỏ hơn 24mm được gọi là ống siêu rộng (ultra/super wide-angle lens). Ống kính góc rộng cũng có dạng tiêu cự cố định (ống fix) và loại zoom với chiều dài tiêu cự thay đổi được.

Ứng dụng ống kính tele trong nhiếp ảnh

Trong nhiếp ảnh, mục đích đáng kể nhất của ống kính tele chính là để tiếp cận đối tượng chụp từ một khoảng cách khi mà người chụp không thể hoặc không nên đến gần chủ thể cần chụp. Ống kính tele có thêm chức năn zoom vẫn luôn là một lựa chọn ưa thích của các nhiếp ảnh gia chuyên chụp ảnh động vật hoang dã, thiên nhiên.

Trong đời sống thường ngày, ống kính tele còn là một lựa chọn lý tưởng để ghi lại những khoảnh khắc tự nhiên nhất của đối tượng cần chụp như những đứa trẻ. Vì với ống kính tiêu cự càng lớn, bạn có thể tiếp cận đối tượng từ một khoảng cách càng xa, đối tượng chụp có thể không nhận biết rằng họ đang được chụp ảnh nên hành động tự nhiên hơn. Tuy nhiên, khuyến cáo rằng người nên chon cách sử dụng ống tele một cách khôn ngoan thay vì tận dụng lợi thế tiếp cận đối tượng từ xa để thực hiện những bức ảnh khó coi.

Với chiều dài tiêu cự lớn, ống kính tele còn được ứng dụng trong chụp ảnh chân dung hay thời trang vì ít bị méo hình, khả năng xóa phông bằng tiêu cự giúp tăng độ tập trung vào chủ thể cần chủ. Đặc biệt, ống kính telephoto zoom cũng tỏ ra rất hữu dụng trong thể loại ảnh phong cảnh nếu người chụp nắm rõ các quy tắc về luật xa gần.

Một số lưu ý khi sử dụng ống kính tele

Đối với những ống kính tele có tiêu cự rất lớn như 200mm, ảnh chụp có khả năng bị nhòe do rung hình cao. Dĩ nhiên là các ống kính tele cũng có những model được trang bị cơ chế ổn định hình ảnh, nhưng với dải tiêu cự quá lớn, tính năng chống rung không thể hoạt động một cách tốt nhất – vì thế, tốt nhất hãy trang bị cho mình một bộ tripod đủ cứng cáp để chịu đựng sức nặng thân máy và ống kính.

Ống kính tele cũng là một lựa chọn tốt cho ảnh phong cảnh. Ảnh: digital-photography-school.

Ống kính tele cũng là một lựa chọn tốt cho ảnh phong cảnh. Ảnh: digital-photography-school.

Khác với các ống kính tiêu cự ngắn, mọi chuyển động/tác động lên thân máy sử dụng ống telephoto/super telephoto lens đều được phóng đại. Ngay cả lực tác động hình thành từ việc nhấn nút chụp ảnh tưởng chừng như rất nhỏ cũng có thể làm hình ảnh bị nhòe vì rung dù cho người dùng có sử dụng tripod đi kèm. Để khắc phục, bạn có thể dùng phụ kiện dây bấm mềm mua riêng vì phụ kiện này cho phép chụp mà không cần nhấn nút shutter release trên thân máy.

Với những ống kính tiêu cự từ lớn đến rất lớn có hỗ trợ chống rung, một khi sử dụng chân máy, người dùng nên tắt tính năng này đi vừa giúp tiết kiệm pin, vừa tăng hiệu quả chống rung hình ảnh.

Như đã nói từ đầu, ống kính tele luôn được trang bị những thành phần quang học đặc biệt để kéo hình ảnh từ xa lại gần. Cũng chính vì điều này mà loại ống kính này thường gây ra hiệu ứng telephoto effect – biến những vật thể ở xa gần như phẳng (tiền cảnh gần như phẳng với hậu cảnh), khó có thể xác định một khoảng cách cụ thể. Tuy nhiên, trong nhiếp ảnh, hiệu ứng telephoto effect hay còn gọi là kỹ thuật làm phẳng hình ảnh đôi khi lại mang lại cho bức ảnh những cảm xúc đặc biệt vì khoảng cách giữa tiền cảnh và hậu cảnh đã bị rút ngắn hơn so với thực tế.

Theo: Pcworld.com.vn