Agile Software Development in point of view

Thế giới Agile ngày càng phức tạp.

Ngày nghỉ cafe thảo luận, tôi cho rằng thế giới Agile đang ngày càng phức tạp. Pham Anh Doi cũng đồng ý rằng, Agile đang bị bias – thành kiến: kẻ thích trở nên cuồng, người không thích trở thành căm ghét.

Bài viết dài, là tập hợp của các ý tưởng lộn xộn. Vì thế bạn có thể nhảy vào bất cứ đoạn nào cũng nhận được các thông tin riêng lẻ; thấy hay thì đọc tiếp, không nhất thiết phải đọc từ đầu.

—–
Agile là gì (và không là gì)?

Tại chính thời điểm này, định nghĩa về Agile hoàn toàn không rõ ràng. Quay lại lịch sử, thuật ngữ này lần đầu tiên được giới thiệu là “Agile Software Development”, sau một cuộc hội thảo giữa 17 người là tác giả của một số phương pháp phát triển phần mềm hiện đại (có tên và không tên), 2001. Họ chia sẻ chung một số phương pháp, nguyên lý… và Manifesto for “Agile Software Development” ra đời với 4 điều trong Tuyên ngôn và 12 nguyên lý.

Vậy là Agile Software Development có định nghĩa từ thời điểm đó, nhưng không bị giới hạn. Sau này có một số phương pháp nữa ra đời, dựa trên những nguyên lý trên, đồng thời khái niệm Agile cũng dần được thay thế cho Agile Software Development và lan dần sang một số lĩnh vực khác. Định nghĩa này chưa bao giờ được “nâng cấp version” một cách chính thức bởi những tác giả cũ cũng như mới nên nó trở nên không rõ ràng.

—–
Agile thế nào (và không thế nào)?

Nhìn lại 4 điều trong Tuyên ngôn và 12 nguyên lý, dễ nhận thấy là chúng khá chung và đúng. Điều này dễ hiểu vì tìm kiếm điểm chung của nhiều phương pháp cũng như đồng thuận của 17 người, đại diện cho 17 tư duy, quan điểm thì khó mà cụ thể được.

Thời điểm đó, Agile là tập hợp của các phương pháp phát triển phần mềm dựa trên sự kết hợp của phương pháp lặp và tăng trưởng. Lưu ý, tôi đang nói về phần “thể hiện” của các phương pháp, không phải “tư duy” (nguyên lý) phía sau.

Nhưng sau này, dựa trên nguyên lý, nhiều thứ khác được coi là Agile với nhưng thể hiện không giống như ban đầu. Người ta bắt đầu nói về no planning, no estimation, no Sprint,… đủ thứ. Một ví dụ là Kanban, nó chỉ có thể hiện phần tăng trưởng, không rõ ràng đề cập tới lặp nhưng vẫn nằm trong Agile.

—–
Agile có gì (và không có gì)?

Lưu ý rằng Agile Software Development cũng phải dựa trên một số nguyên tắc về quản lý, cách tổ chức nói chung nhưng những thứ này không được định nghĩa rõ ràng. Điều này dẫn đến một số hiểu lầm khá tệ. Ví dụ như “self-organized team” và “cross-functional team”, Agile sử dụng mà không sở hữu; vậy nên không thể hiểu chỉ Agile mới xây dựng những team như vậy. Hay như mô hình về team stage của Tuckman cũng không thuộc về Agile. Kỹ thuật 5Whys, Kaizen… cũng vậy. Đó là những công cụ để nhóm hay người quản lý nhóm thực hiện tiến hoá quy trình.

Tương tự, DevOps ra đời sau, và “có liên quan” tới Agile. Nhưng ngày nay, cách hiểu Agile quá lớn nên DevOps được hiểu như là “nằm trong”. Holacracy?

Trách nhiệm có lẽ thuộc về những nhà tư vấn, đào tạo không phân biệt rõ, gây ra những hiểu nhầm rằng “Agile là con đường duy nhất để đạt được những điều này”.

—–
Agile hướng tới gì (và không hướng tới gì)?

Agile hướng tới giá trị (value oriented), không hướng quy trình (process oriented). Quy trình trong Agile cũng buộc phải thể hiện được giá trị mới có lý do để tồn tại. Để tìm được giá trị, bắt buộc phải trả lời câu hỏi “tại sao (why)?”. Để tìm được quy trình, câu hỏi là “thế nào (how)?”. Câu hỏi why khó hơn rất, rất nhiều câu hỏi how. Và thông thường, để trả lời được câu hỏi why, chúng ta cần dựa trên how đang tồn tại.

Rắc rối ở đây, các nhà tư vấn, huấn luyện hoặc quản lý mong muốn đưa how vào trước; và kỳ vọng thời gian sau tổ chức sẽ tự trả lời được câu hỏi why. Công bằng mà nói, cách làm này không sai, nhưng nếu why không dần được tổ chức nhận ra, họ vẫn cứ loay hoay trong how. Và vô tình, Agile trở thành process oriented. Dù vậy, các “process” trong các phương pháp Agile vẫn khá tinh giản (so với các mô hình phát triển phần mềm khác), nên các team đã có quy trình trước đó khi chuyển sang Agile vẫn thấy bình thường. Điều tệ hại là, hầu hết các team ngày nay đều không áp dụng một phương pháp nào trước đó cho tới khi thực hành Agile, họ bỗng thấy Agile “cồng kềnh” và trở nên căm ghét.

(Ví dụ, team trong Scrum là self-organized, thật khó tin là đưa 5, 7 con người vào một team và hy vọng self-organized được nên vẫn cần có một số quy tắc, quy trình cơ bản ban đầu; nếu team không có sự tiến hoá, sẽ trở thành process oriented).

Sau không trào “doing Agile”, giờ là phong trào “being Agile” – dù không dễ, tôi vẫn thấy nó thiết thực. Nhưng “go Agile” thì không. Tôi chẳng biết trông nó sẽ thế nào.

—–
Agile phù hợp với gì (và không phù hợp với gì)?

Nên nhớ, Agile ra đời với “Agile Software Development” tức là để giải quyết bài toán của phát triển phần mềm. Scrum nói rõ nó phù hợp với các dự án / sản phẩm nằm trong miền “phức hợp và phức tạp tương đối” về yêu cầu và kỹ thuật – tức là các dự án / sản phẩm đơn giản (đã rõ ràng) hoặc quá phức tạp (VD: R&D, công nghệ quá cao…) cần được xem xét. Thế nào là đơn giản, phức tạp… phụ thuộc nhiều yếu tố: con người, trình độ, công cụ,… nên (ví dụ) Scrum có thể phù hợp với team này ở sản phẩm này nhưng không phù hợp với team khác ở chính sản phẩm đó.

Agile dựa trên giả định về việc “chào đón sự thay đổi” (welcome change, Scrum: adapt to change, XP: embrace change); tức là, mọi cá nhân trong tổ chức đều thống nhất rằng “thay đổi là điều được chấp nhận”. Tổ chức không đồng tình với sự thay đổi, không “chào đón” mà áp dụng Agile là sai từ gốc.

Hầu hết các phương pháp Agile đều dựa trên gỉa định “cá nhân có động lực làm việc” nên các tổ chức còn loay hoay trong việc này cũng nên cẩn trọng.

Nếu nhìn lại các câu hỏi đã được trả lời trên, Agile có thể giải quyết rất nhiều bài toán khác, không chỉ với việc phát triển phần mềm (trong Agile Y tôi còn nói tới cá nhân). Cùng với sự thống trị của các công ty công nghệ (mà lõi là sản phẩm phần mềm), Agile lan rộng sang những lĩnh vực khác, “nuốt chửng cả thế giới”. Cần lưu ý:

– Vì vậy Agile càng không rõ ràng.
– Các lĩnh vực khác không có chỉ dấu rõ ràng về hiệu quả vượt trội của Agile như trong phát triển phần mềm – nơi Agile ra đời do trải qua sự khủng hoảng về phương pháp.

hãy cẩn trọng.

—-
Agile trở thành “thuốc chữa bách bệnh”.

Agile thực sử trở nên không rõ ràng. Cách hiểu gần nhất (của tôi) có thể là “Agile là công cụ (mindset, toolset) để tăng tính linh hoạt (agility) của tổ chức, qua đó thích ứng tốt với thay đổi (hoặc dẫn dắt thay đổi)”.

Và cho đến giờ này, đây có vẻ là “bệnh” rõ nhất của các doanh nghiệp; và với hổ lốn những thứ được gắn tag Agile, Agile có vẻ được kỳ vọng quá lớn để chữa bách bệnh.

Và khi không chữa được, đương nhiên Agile bị đổ lỗi.

Như trên, tôi cho rằng trách nhiệm nằm ở những nhà tư vấn, đào tạo Agile trong việc rạch ròi Agile là gì, và Agile trong phạm vi anh cung cấp dịch vụ là gì, nó thế nào, hướng tới đâu. Bằng cách vơ vét tất cả mọi thứ vào Agile cùng sự quảng cáo quá đà, gây ra sự ảo tưởng về sức mạnh từ tổ chức.

—-
Agile trở thành “đạo”.

Agile dự trên pull-system, giả định “cá nhân có động lực làm việc”, điều này đi ngược với phần lớn cách tư duy về quản lý hiện có. Dù có hệ thống lý thuyết chặt chẽ đứng sau, Agile vẫn cần niềm tin để thực hiện trong tổ chức. Khi phương pháp cần tới “niềm tin” là điểm xuất phát thì nó không khác gì “đạo” – sẽ có kẻ sùng đạo và phản đạo.

Có fan và anti-fan là điều dễ hiểu.

—–
Scrum đã làm tốt gì (và không làm tốt gì)?

Scrum thực sự tuyệt vời. Nó là một mô hình tuyệt vời với đủ sự tinh gọn, hiệu quả cho phép tổ chức “nhận diện vấn đề”. Đây là điều siêu quan trọng để phát triển sản phẩm cũng như phát triển tổ chức.

Scrum không làm việc giải quyết vấn đề. Vậy nên nếu nhóm không giải quyết những vấn đề được nhận diện, Scrum là đống rác cạnh hàng ăn. Nhưng có phương pháp nào giải quyết vấn đề không?

Scrum làm tốt trong việc ghi chú “Scrum dễ hiểu, khó làm chủ”.

Scrum (đúng hơn là các tổ chức cấp chứng chỉ Scrum (Master, Developer, PO)) làm không tốt trong việc đào tạo. Khá dễ dãi. Có 2 lỗ hổng lớn, khiến các ScrumMaster cầm chứng chỉ và nếu không chịu học hỏi thêm sẽ mắc phải:

1. Không trả lời được rõ ràng các câu hỏi trên. Cái gì thuộc Scrum, cái gì không? Dẫn đến ngộ nhận trong lỹ thuyết lẫn thực hành.

2. ScrumMaster không yêu cầu kiến thức về phát triển phần mềm. Về lý thuyết, điều này không sai; song thực tế thật khó để tham gia vào nhóm phát triển phần mềm mà không hiểu gì về cách nhóm thực hiện.

Từ đây dẫn tới những hệ luỵ vô cùng phức tạp. Chuyển giao cái gì? Technical debt là gì? Simple design là gì? Xử lý thế nào? Tài liệu thế nào là đủ?…

ScrumMaster yếu về chuyên môn (ngành) và non tay dẫn dắt nhóm có trình độ cao hơn mình sẽ là thảm hoạ. Đội bóng cần HLV tương xứng. Vấn đề là, tốc độ phát triển của thành viên Nhóm phát triển thường nhanh hơn (và khởi đầu tốt hơn) những ScrumMaster. Vậy nên nhiều nhóm phát triển bắt đầu chán ghét Scrum.

Trách nhiệm này thuộc một phần vào các tổ chức cấp chứng chỉ Scrum, phần lớn thuộc về các ScrumMaster khi không thể hiện được vai trò tương ứng, và cả các nhà đào tạo – không trang bị đủ hệ thống lý thuyết và thực hành.

—–
Trách nhiệm của những nhà đào tạo, tư vấn?

Đừng trách sự tồn tại của những nhà đào tạo, tư vấn. Đừng trách những quảng cáo, khóa học. Đó là nhu cầu tất yếu, và thiết thực, bởi họ giúp rút ngắn con đường tổ chức tiếp cận Agile (nếu muốn). Nếu họ làm việc trên nguyên tắc cung cấp đúng giá trị và đạo đức.

Nhưng, đến lúc này, tôi cho rằng những nhà đào tạo, tư vấn cần phải có câu trả lời rõ ràng cho mình, cho khách hàng rằng với anh, Agile là gì (và không là gì), Agile (trong phạm vi đó) mang lại giá trị gì và lấy đi gì…?

Giống như bác sỹ, cần rõ ràng rằng những thành phần này là gì, tổ hợp lại được gọi tên gì, chữa bệnh gì, chống chỉ định gì, tác dụng phụ gì…?

Tuyệt nhiên không thể mông lung như Agile làm nhóm hạnh phúc hơn, Agile giúp tăng năng suất, Agile giúp tăng tốc độ hoàn thành dự án… – những điều Agile nguyên thuỷ không hề đề cập.

—–

How to define good software engineer

That is a lot of “givens” for an “average” software engineer. In reality, the great software engineer solves problems in hours that the average engineer will never solve correctly. The great software engineer solves ordinary problems in one-third the time with one-fifth as much code and one-tenth as many bugs. The great software engineer’s code runs in O(n) while the average software engineer’s code runs in O(n^3) time. The great software engineer can adapt his solution while you wait, while the average software engineer complains about late changes to the spec and says it will take weeks to meet new requirements now. These are all real differences I have seen when a great engineer redoes the work of the average engineer.

Thế nào là Engineers giỏi. Đọc thảo luận của các bạn trên stackoverflow về câu nói của Bill Gates: Engineer xuất sắc giá trị gấp mười ngàn lần trung bình. Thấy có có một comment mà đọc thấy chuẩn quá:

Các kĩ sư xuất sắc giải quyết vấn đề theo giờ, còn các engineer trung bình không bao giờ giải quyết được chính xác.

Các engineer xuất sắc giải quyết vấn đề gốc trong 1/3 thời gian, 1/5 code và 1/10 số lượng bug so với Engineer trung bình.

Các Engineer xuất sắc viết code chạy với độ phức tạp O(n), còn các engineer trung bình viết code với độ phức tạp O(n^3).

Các Engineer xuất sắc có giải pháp hích ứng với các thay đổi, trong khi các engineer trung bình phàn nàn về các thay đổi bị đưa vào yêu cầu trễ, và đòi thêm hàng tuần để sửa đổi.

Source:

Jim Hagemann Snabe, former SAP co-CEO and now SAP alumnus, shares insights about the future of work and has four personal messages for employees.

Jim Hagemann Snabe – I’ve spent time on five different boards, including SAP’s of course. This year, I was asked to be the chairman of board of A. P. Moller Maersk, the largest container shipping and logistics company in the world. In January next year, I’m nominated to take over as supervisory board chairman of Siemens, one of the world’s largest industrial conglomerates. On top of that, I’ve kept my role at Allianz, where I’m now a vice chairman.

what could SAP’s contribution be to them?

In manufacturing, the assumption so far was that companies relied on mass production in low-cost locations. I think we’re now moving production back closer to the customer. Instead of mass-producing, companies will be producing individual items and, as such, delivering more accurately on individual customers’ needs. I actually believe that we have an opportunity now to rethink the value chain and move toward more circular economy concepts where we don’t consume resources, but use them and give them back ‒ for a much more sustainable future.

I believe that we now probably have the biggest opportunity ever in terms of creating a society that is significantly better than the one we have today. We can create or reinvent entire value chains for something that’s better, more individual, and much more sustainable. The challenge will be the transformation itself. How do you get there? It’s a very big change, so it will dramatically change the way we do things: It will challenge existing jobs and create new ones. So major reskilling will be necessary.

I believe the winners will be the companies that master the physical and the digital worlds in parallel. And a lot of the work I do in my board roles is to help accelerate the digital dimension in physical companies like Siemens and A. P. Moller Maersk, so they can master both in parallel.

 

What is your message to SAP employees?

Jim: First of all, I miss everyone at SAP. Secondly, I would send a big thanks to Bill McDermott for being such a great partner, leader and friend. SAP is a very special company with not just a big brain, but also a big heart and very capable hands. I would urge everyone to be extremely proud of what you’ve achieved and of the special DNA that the company has. Keep that!

At the same time, my message would be: Be ambitious and challenge assumptions! Because you can’t succeed in the future by looking back at historic successes. You have to keep challenging your assumptions so that you always stay relevant and ahead of the game. SAP has proven its ability to reinvent itself from a position of strength. Keep doing that, at an even higher pace in the future.

My third message would be: Make sure you develop the capabilities that matter the most! Which is really about unleashing human potential and allowing experiments, while increasing efficiency at the same time. Being ambitious on efficiency unleashes the capacity and investment opportunity for the experiments, and it’s the experiments that will create the future. But you have to make sure those two elements go hand in hand.

My last point is: Never forget the customer! The companies that fail to reinvent themselves from a position of strength are those who get obsessed with themselves. I believe that SAP has always been about the customer, and if we keep that in mind, the company has the potential to be extremely successful in the future.

 

SAP clearly plays a very important role in the world. That’s a reason to be proud, but it also carries enormous obligations.

 

By Andrea Diederichs

(Just copy from SAP and using it for my-self, do not use this if do not ask)

Benchmark – Node.js vs Java

by benchmark task performance

regex-redux
source secs mem gz cpu cpu load
Node.js 4.02 507,480 452 4.02 0% 1% 100% 0%
Java 12.16 927,212 929 37.28 73% 81% 75% 78%
n-body
source secs mem gz cpu cpu load
Node.js 27.82 28,208 1297 27.81 1% 0% 1% 100%
Java 21.50 27,240 1489 21.52 1% 1% 100% 0%
mandelbrot
source secs mem gz cpu cpu load
Node.js 17.49 564,704 778 62.77 84% 84% 96% 97%
Java 5.89 89,504 796 23.08 98% 98% 98% 99%
reverse-complement
source secs mem gz cpu cpu load
Node.js 3.68 245,496 1088 3.93 4% 4% 98% 2%
Java 1.11 345,308 1661 2.44 33% 58% 54% 80%
spectral-norm
source secs mem gz cpu cpu load
Node.js 15.77 28,804 425 15.77 1% 0% 1% 100%
Java 4.29 31,428 950 16.56 97% 96% 98% 97%
fasta
source secs mem gz cpu cpu load
Node.js 9.45 31,892 1745 9.46 1% 1% 1% 100%
Java 2.14 36,192 2457 5.68 71% 58% 62% 77%
fannkuch-redux
source secs mem gz cpu cpu load
Node.js 78.41 27,192 473 78.39 1% 1% 100% 1%
Java 17.74 30,048 1282 69.90 98% 98% 100% 99%
binary-trees
source secs mem gz cpu cpu load
Node.js 50.22 927,540 440 51.07 6% 15% 77% 6%
Java 11.33 592,668 835 39.39 84% 92% 83% 91%
k-nucleotide
source secs mem gz cpu cpu load
Node.js 60.73 2,095,052 904 151.74 96% 84% 84% 83%
Java 8.02 467,004 1802 25.57 76% 98% 73% 74%
pidigits
source secs mem gz cpu cpu load
Node.js Bad Output
Java 0.24 828 938 0.24 71% 38% 8% 4%
Node.js v7.6.0
Java java version “1.8.0_121”
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

Using Swagger to define API RESTful endpoints

It then generates API Documents and Application Skeletons for you. Afterward, you can write code to implement the APIs’ functionality. Another similar tool is RAML.

I personally think that if you are using Ruby, you can just write a good README file about APIs, and done with it. It will be much faster and  cleaner, if you know what you are doing. However, if you run a project that build multiple services by different teams with different skill levels, things such as Swagger and RAML will help you to maintain a certain level of unification of different codebases. And those tools also help to keep the APIs in synch with API docs (Lazy developers will like this feature).

This article describes step-by-step  of using Swagger to define API functions, generate a Sinatra skeleton web-based app and write code to implement the app. The Sinatra skeleton generated by Swagger does not work out of the box, and the quality of Ruby code is terrible, so I have to do some modifications myself to make it work and be bearable.

The steps are:

  • Write YML file that contains API definitions.
  • Generate and download the Sinatra skeleton.
  • Modify the code to make it work.
  • Implement the APIs’ functionality.
  • View API documentation and test the functionality from Web browser.

I. Prerequisites

There are Swagger tools that you can download and use offline on your computer. To me, they are not attractive, so you can see about downloading and installing them here.

But to use online tools, you just need a web browser. I test the tools with Chrome and Opera on Mac OS X, and they work.

 

II. Write YML file that contains API definitions

Use your web browser to go to the Swagger YML Editor:  http://editor.swagger.io/#/

On the browser, you will see this screen if you come to Swagger Editor the first time:

 

Click on the button “Got it!”, you will come to a screen to edit the YML file that describe your APIs. In the editor on the left side, you will see the YML definition of the example app Uber API like this:
You can delete everything in the YML editor on the left, and write your own API definitions there. I already wrote the YML definitions for two APIs of Email Services in this YML file.

POST /verifications.json

When a user registers a new account on a site, developer can use this API to send verification email to user’s email address. User must click on the comeback_url to come back to the site to prove that his email is valid.

 

POST /invitations.json

When a user or an organization invites a user to participate a site, developer can use this API to send the invitee an invitation email. The invitee can click on the invitation email to come to the site.

 

Both API endpoints accept JSON parameter with this format:

{
“organization_name”: “Some Organization Name”,
“recipient”: “somebody@some-email.com“,
“comeback_url”: “Some full URL, including protocol http/https”
}

 

For example:

{
“organization_name”: “Amazon”,
“recipient”: “somebody@rubygems.org“,
“comeback_url”: “http://rubygems.org
}

You can read details about YML and JSON specs for API definitions here: http://swagger.io/specification/ .

It is always easier, faster and cleaner to use YML to define APIs.

 

III. Generate and download the Sinatra skeleton

For now, you can copy this YML file written by me, and paste it into the YML editor on the left side of the screen on browser, you should see the screen like this:

 

 

After you copy/paste the YML file in the YML editor and verify on the right side to see the APIs verifications and invitations get defined correctly, you can download the Sinatra Server skeleton by clicking on the menu Generate Server, and select Sinatra.

A zip file called sinatra-server-generated.zip will be downloaded to your local machine. Extract the file, you will have a directory called sinatra-server. That is your Sinatra Server skeleton generated by Swagger. Feel free to change the directory name to any name you want.

 

 IV. Modify the code to make it work

The generated Sinatra skeleton has some troubles, so it does not show APIs or anything out-of-the-box as it supposes to do. Besides, the Ruby code quality generated by Swagger is terrible. So we need to do some modifications to make it work.

1) my_app.rb

Add require to include the files in ./api/, so the application will know about the API endpoints’ definitions.

2) lib/swaggering.rb

– Method self.add_route:

The line “accepted = case method” never works, because the method names in APIs are generated as UPPERCASE, while the accepted tests for the method names uses lowercase.

And the way the code is written to check for valid method names are super dumb. Please look at the modified file for a much better and cleaner implementation.

 

– Method self.to_api:

This method hardcodes base_path in api_listing to the one in @@configuation. It makes the API docs stop working if the application is deployed to any place other than “http://localhost:4567”.

Please look at the modified file for a much better and cleaner implementation.

3) Two files invitations_api.rb and verifications_api.rb

The two API endpoints are defined in these two files.

The API definitions, routes, resourcePaths and endpoints must be modified to reflect (to some degree) the correct APIs defined in the YML Editor (See the right side).
Please look at the modified files invitations_api.rb and  verifications_api.rb, at the parameters of MyApp.add_route.

 

After the 3 steps above, you should be able to fire up the server using the command rackup -p 4567 config.ru.

Then  you can use any REST client, for example Postman to test the APIs at:

POST http://localhost:4567/invitations.json

POST http://localhost:4567/varifications.json

In both cases, you should receive back a JSON:

{“message”: “yes, it worked”}

Now we can start to implement the functionality for the email APIs.

 

V. Implement the APIs’ functionality

I implement the Mail functionality using the gem ActionMailer.

Everything follows the Rails conventions: the mailers are in ./app/mailers/. The mails’ contents are in ./app/views/.

Take a look at the repository for implementation details.

You must configure the email sending configuration in the file ./config/initalizers/setup_email.rb to be able to send mail.

If you run the application on any OS that has postfix, you can configure the file ./config/initializers/setup_email.rb like this:

ActionMailer::Base.raise_delivery_errors = true
ActionMailer::Base.delivery_method = :sendmail
ActionMailer::Base.view_paths = File.join(‘./app’, ‘views’)

 

VI. View API documentation and test the functionality from Web browser

I add the directory public with modified Swagger UI to the application, and add two new routes in the file my_app.rb to support the API docs functionality. It allows users to view API docs, regardless where the application is deployed.

Once you finish all the modifications and APIs’ implementations, run the server with the command rackup -p 4567 config.ru, then you can see the API docs by open this URL in browser:

http://localhost:4567/api_docs

Replace localhost:4567 with the real URL where you deploy the application. You should see something like this:

 

You can click on “Show/Hide” and “List Operations” to view details of each API endpoint.

 

 

You can try out the APIs by clicking on “Expand Operations“. Once you click on “Expand Operations“, you will see a screen similar to this:

 

You should be able to paste parameter similar to the following JSON in to the text box Value, and hit “Try it out!” to see the API endpoint run.

{
organization_name“: “My Awesome Organization”,
recipient“: “somebody@some-email.com“,
comeback_url“: “http://www.google.com”
}

 

For your convenient, I put the fully implemented application here: https://github.com/linhchauatl/sinatra-email-services-server

Please read the README file about how to bring it up and running.
Happy swaggering!

 

Source:hanoian.com

Official NASA Software

It is great news that NASA has released an official software catalog 2017-2018 for various technical applications. Time to learn from BIG Brother.

  1. Business Systems and Project Management
  2. Data Servers Processing and Handling
  3. Materials and Processes
  4. System Testing
  5. Propulsion
  6. Electronics and Electrical Power
  7. Operations
  8. Structures and Mechanisms
  9. Environmental Science
  10. Design and Integration Tools
  11. Crew and Life Support
  12. Autonomous Systems
  13. Vehicle Management
  14. Data and Image Processing
  15. Aeronautics

 

Idea apply ML for Finance and Logistic

Finance

Finance - Machine Learning

Finance – Machine Learning business ideas from the latest McKinsey report.

Logistics

Logistics

Logistics

 

Recap from GS Leadership offsite

HCM – A ‘Cloud Day’

SAP Customer 2017

4 priorities regarding to SuccessFactors:

  • migration from Oracle to Hana,
  • eliminating support issues to improve customer satisfaction,
  • integration within SFSF suite and
  • integration with other SAP products.

putting new codes in SFSF cloud solution today means upgrading 35,000+ schemas for 6,000+ customers in one go. This requires absolute quality focus.

AirBnb

  • ~3K employees (1.5K in San Francisco and 650 are Engineers)
  • ~ 3 million homes (over 2 million booked last New Year’s Eve)
  • Changing their architecture to scale (~100 microservices)
  • They apply Geoffrey Moore’s zone methodology to their work to move past the “innovator’s dilemma”
  • Everyone’s focus is to “drive impact”
  • Engineers are measured against the following expectations: tech ability, productivity, impact, scope, autonomy, influence, and enrichment.
  • Interesting fun fact: When they expanded into Cuba, the country didn’t have online payment infrastructure. Airbnb had to find creative ways to pay the Airbnb hosts (ask one of us for more details about that interesting fact!)
  • As they continue to expand, keeping up with various country legislation is becoming a challenge (and yes, we did mention our tax service J).

 

Machine Intelligence landscape

Machine learning

Machine learning

 

Author: collecting from shivonzilis.com