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.
Well, this approach has three major benefits.
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.
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.
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.
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.
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.
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 should you choose to use Angular on your current project?
Before I answer this, let me takes a step back.
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.
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.
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 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?
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.
So, why did I choose Angular over Ember?
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.
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.
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.
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.
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.
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.
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.
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%.
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).
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.
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.
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.
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.
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.
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.
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.
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!
​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.
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.
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.
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.