This is very simple version of building your own Jarvis basing on what we have today. The Jarvis here can recognize and do some commands like showing the lunch menu, display menu of a specific day… etc. It’s less than a prototype but it can be the demo of what we can do by combining:
  • Speech recognize: It’s much easier today with Apple, Google and some others open the SDK. Many languages are supported but English is the best, of course.
  • Natural language understanding (NLU): Most of big tech companies are working on the promising system like LOUS.ai (Microsoft), Watson (IBM)… I use Wit.ai just because of its simple of use. These systems created the base model, our task is just inserting more data to train the machine with a specific topic.
  • Natural language processing (NLP): It’s actually the lower level of NLU but it could help. Google is in the best with cloud base service https://cloud.google.com/natural-language/, that can analyze the syntax and sentiment. It’s really helpful while we combine the NLU and NLP. We know the intent of the sentence as well as sentiment, it’s a guide to have more human react (with emotion). 
  • Text to speech: It’s a easy job, there are a lot of services help our Jarvis speak naturally like Amazon echo.

We can do somethings base on this code. Objectively, we can connect it with other things like laptop, IoT server… to do more jobs such as sending the message, turning on the light… etc. Technically, we can have better design to open for the possible command / intent, and think about the serverless jobs.

I hope I can do further in the next demo.

The presentation and source code are here: https://github.com/hiennvn/simple-jarvis 

 

511 total views, 1 views today

Here is my presentation for the workshop at CodeGym today about Design patterns. One of the biggest issue in training design patterns is the trainees don’t know how to apply them together in a single real world problem. I tried to create a real world problem and introduced a simple way to get it solved by combining some design patterns.

KFC. Order system

KFC is very famous fastfood brand, they have many franchises in various places that share the same hotline, menu.

When users open the menu on KFC website, they see the single menu, choose and order food by calling to the single hotline. A order center (OC) receives the order and notifies to the appropriate store by a specific criteria (now is location and can be changed in the future). A store can answer their possibility to take this order (they need to cook and deliver it on time). If a store takes this order, the process ends; otherwise, the OC will find another one.

To process a order, a store has a recipient who receives the order from OC, forwards it to the kitchen, finds the right delivery man and updates the order basing on the information from delivery man such as payment, status (accepted or declined), customer feedback… to OC. So OC has real time data of every orders but doesn’t have order’s internal note that works within the store.

When OC gets the order information from customer, they may get the extra information in some categories like food change, delivery time, special notes… If customer calls to OC to cancel the order, OC can directly cancel it by updating the order status in taken store.

Design the system by design patterns.

446 total views, no views today

I will have a workshop at CodeGym at the end of this month about Design patterns. One of the biggest issue in training design patterns is the trainees don’t know how to apply them together in a single real world problem. Here is my example that will be used as the exercise for this workshop. Is it interesting enough? Try it out.

KFC. Order system

KFC is very famous fastfood brand, they have many franchises in various places that share the same hotline, menu.

When users open the menu on KFC website, they see the single menu, choose and order food by calling to the single hotline. A order center (OC) receives the order and notifies to the appropriate store by a specific criteria (now is location and can be changed in the future). A store can answer their possibility to take this order (they need to cook and deliver it on time). If a store takes this order, the process ends; otherwise, the OC will find another one.

To process a order, a store has a recipient who receives the order from OC, forwards it to the kitchen, finds the right delivery man and updates the order basing on the information from delivery man such as payment, status (accepted or declined), customer feedback… to OC. So OC has real time data of every orders but doesn’t have order’s internal note that works within the store.

When OC gets the order information from customer, they may get the extra information in some categories like food change, delivery time, special notes… If customer calls to OC to cancel the order, OC can directly cancel it by updating the order status in taken store.

Design the system by design patterns.

—————————————————————-

The solution will be updated later.

437 total views, 1 views today

Following the topic in my short post eXtreme Programming is Dead, I had a talk at the monthly meetup of Agile Vietnam, Feb 2017, to explain more about my opinion.

Half of time, I focused on describing what exact eXtreme Programming (XP) is. Today most of development teams are applying some XP practices but they just do it with forgetting what are behind the scene: values and principles. It’s time to recall to how to do it right.

Then I explain more about my idea, why XP is dead. It’s dead in some ways: teams just follow the practices without knowledge of values and principles, the practices is more and more becoming standards of software development instead of extreme, original XP makes the confusion of applying it at enterprise.

You can find the slide here – it just is the outline, I will try to explain more in longer post later.

280 total views, no views today

I had a talk in monthly meetup of hocvienagile.com, July. And here is a slide. In fact, some few words in the slide cannot express my idea clearly enough while our discussion was very interesting. It’s not easy to write these ideas in a short article but it’s nice for some notes:

  1. Agile is for speed, budget…? No. In business perspective, Agile is for value while Agile is for quality in developer’s view. Agile is a method to adjust / negotiate between the constrains of scope, time and budget to get the highest value / quality in the current situation.
  2. Agile team is happier than non-Agile team. Not sure. If we don’t use the negotiation to adjust these constrains in the right way, Agile team never has chance to be happier.
  3. Agile is built for fast success. No. There are many tricks to get a Agile team successful in the early stage but it’s normally a trap.
  4. Scrum is the best Agile framework. Not sure. About 50% of Agile-share doesn’t show that Scrum is the best Agile framework. Every Agile team should start with Scrum because it’s easier and has clear guideline with specific roles, events…etc.  But when the world is changing fast from development-in-black-box to operation stage, Scrum is going down due to limitation of Sprint goal.
  5. Always say no to ScrumBUT. Not sure. If we are aware that ScrumBUT is being used in reasonable way, it’s fine. Read more here.
  6. Scrum needs 5 core values to success. No. If a team has 5 core values (as Scrum mentions), they would be successful no matter Scrum or another framework is being used. It’s not a required values to start a Scrum team, it’s a target for having high performance team. If a Scrum team doesn’t have, find the right ways from 3 Scrum pillars to get them up.
  7. Agile works without XP practices. No. Never. I have never seen any Agile team (in software development) be successful without XP. XP is the most important thing in Agile umbrella.
  8. Retrospective never talks about people. We should talk about processes, tools and also people. But please do it in constructive way, for both people who give and receive feedbacks. Please not that “Individuals and interactions over processes and tools” is mentioned in Agile Manifesto.
  9. Agile team needs stability, so small turnover-rate is good. Not sure. We also need the new knowledge and change by getting Agile team in a downer stage with new guys.

325 total views, no views today

My talk about the life although I learn the knowledge and technique from my daily works.

It’s actually too short for my 1.5 hour talk but this slide can cover my ideas for having a happy life. Here are:

Firstly, we need to understand what the life is. I recommend the great book Our Ultimate Reality, Life, the Universe and Destiny of Mankind by Adrian P. Cooper who is the mind leader of mankind. I learnt too many things in this book, from the the ‘basic things’ such as human, life, money…etc to the life laws.

Secondly, we need to understand ourself. It’s the key to know exactly what make us happy in the daily life. In fact, a person feels happy in his good point that the 4 parts of a human balanced: body, emotion, mind and spirit. This point, of course, is very different for each person.

When we know the point where we feel happy while standing on, we know exactly who we will be. Then we try to be? No, trying makes us unhappy. We need to think we are being and staying this point – it makes us happy (just because we know that it makes us happy) :). If we want to be the rich men, we need to think that we are the rich men and we act like the rich men. If we want to be the nice men, we need to think that we are the nice men and we act like the gentlemen, treat everybody by the nice actions. It’s the attraction law; if we act like the rich men, we attract the Source to give us money; if we act like the gentlemen, we attract the Source to give us the good mood, good spirit and open mind. The law that you can find in any self-help book.

BUT how we act like a rich men if we don’t have money? How we act like the gentlemen if we are feeling stress? That’s no self-help book gives us 🙂

Then I find the root cause is how we deal with our works to let us more productive to make money, to reduce stress,… and achieve the success to make us happy.

Manage works is for productivity

Manage productivity is for improvement

Manage improvement is for success

Manage success is for happiness

Manage happiness is for life

While we have a good way to manage our works, we are more productive and increate both quantity and quality of works. It makes us having good enough time, energy and attention for the things that make us happy.

While we look back to find the way to increase our productivity, we are improved. It makes us reaching to the next level, and we are always looking for the new things that make us happy.

While we have a lot of improvement, we are ready for the success. No matter our starting point is, if we improve ourself day by day, we will be of course successful. No matter small or big success, it makes us motivated and happy.

Then think big but do small. Small achievements make us happy day by day to build the big success. That’s called manage success.

But my talk just stop at the “manage productivity for improvement”, if you think it helps, I will go forward with the rest points 🙂

649 total views, no views today

Here is my presentation in the monthly meetup of Agile Vietnam in August, 2015. In this session, I shared our approach and implementation for current Agile project in both mindset, team structure and technical aspects. It’s really good that I got a lot of questions during my presentation time and feedbacks afterward – lot of them conflict with my share in some points or wholeness. If you have something like that, please comment or contact me for the open discussion as you are a testing domain master who may have different approach to me, an Agile / Lean fan and have another view point of whole project and don’t just focus on testing area.

But please note:

  • My share is just in Agile project. It maybe incorrect for another project that doesn’t follow Agile method. For example, “the total cost usually doesn’t change” seems incorrect in a traditional project.
  • Our specific doings are not new or magical things – they are just a normal things that you are doing in any project. For example, unit testing is as the same as it in any project. BUT my idea is the wholeness where we can combine the separated things together and make it automated and run it everyday. It recalls to Agile testing manifesto “testing throughout over testing at the end” to “defect prevention over defect detection”. I’m sorry for lacking of recall to my share before about our continuous integration, you could find it here – it’s not the project I showed today but the idea is the same.
  • It may conflict to you because it seems to decrease the importance of tester (QC, QA) role or work. No, it helps tester (QC, QA) reduce her works by quality built-in but cannot replace her importance.

And here is my view points (again, in Agile project):

Automation testing is not a tool that let us work from Monday to Thursday and let the machine do your repeatable works in Friday. It’s a method to let us work from Monday to Friday safety by knowing our issues and preventing bugs everyday.

Yes, it recalls to“testing throughout over testing at the end” to “defect prevention over defect detection”.

We have to do the manual works for automated test, includes the testing for it. So more automated testing could be done, more manual work may need to be done.

Remember we usually refactor code / structure in Agile project instead of having a fixed design in traditional method, so we need to continuously maintain the test afterward manually.

The total cost usually doesn’t change. But whenever we want to execute large set of test cases in a short time, we can – that we normally cannot do by using people.

That means if you need to spend cost (people, effort, money, time…) for testing, its total usually doesn’t change, no matter that the automation or manual testing is implemented. So please define your objectives of applying automation testing. If you care about time reduction, please spend more money or people. Or if you care about people (team improvement), please spend more time. In my opinion, you could benefit more from automation testing in waterfall project than Agile project in maintenance cost (as it usually doesn’t change) BUT it doesn’t help in quality built-in and continuous integration run.

More unit test, fewer UI test.

Could you remember the automation testing pyramid?

Thousands thanks to you for spending time hearing me. Millions thanks to you with your feedbacks, especially your disagreements – just comment or contact me for open discussion. I may call for a coffee for the discussion in very next day, would you like to join?

1,343 total views, no views today

The introduction to Scrum in TapLife, shared in 2 hours with the product teams.

After a short introduction, they talked about the current context to get my shares.

Taplife is a startup, building some great mobile apps that are focused on the augmented reality. They are facing some common startup issues: looking for the effective working methods in the software development as they “seem” be following waterfall right now by the content team goes first with full specifications, design team make them visual on UI and developers end up by code implementation. It of course takes more time to make an idea go live.

175 total views, no views today