Khung ảnh ếch và heo

Chuẩn bị những dụng cụ này nhé:
– Vải dạ các màu

– Kéo, kim chỉ

– Bông
Bước 1:

– Cắt vải dạ hồng thành hai miếng đầu, một cái mũi, hai má, hai thân , hai cánh và một mắt cho chú heo.

– Cắt 3 miếng hình vuông (2 rỗng và 1 không rỗng) cùng những hình trang trí khác.

Bước 2:

– Khâu trái tim vào thân heo và khâu má, mắt, mũi cho phần đầu chú heo.

Bước 3:

– Khâu hai miếng thân lại với nhau rồi nhồi bông bông vào.

Bước 4:

– Tương tự, khâu hai miếng đầu lại với nhau rồi nhồi đầy bông vào các bạn nhé!

Bước 5:

– Ráp đầu và thân bé heo lại và đính thêm một cái nơ ở phần cổ.

Bước 6:

– Tiếp theo, mình may chập hai miếng khung hình vuông lại với nhau. May bốn cạnh bên trong và một cạnh bên ngoài.

Bước 7:

– Cuối cùng, các bạn may miếng hình vuông vào mặt sau rồi đính các phần trang trí lên mặt trước. Các bạn chú ý chỉ may 3 cạnh, chừa lại một cạnh để cho hình vào nhé!

Cùng lồng ảnh vào khung và ngắm thành quả thôi!

Các bạn nhớ đính cả dây nối giữa 2 phần khung ảnh để có thể treo lên nhé!


JSF c:forEach vs ui:repeat


This is probably one of the most frequently asked questions on the JSF mailing list. Why doesn’t my c:forEach tag work correctly? Unfortunately, there are may ways to misuse the JSTL tags available in JSF, so the answer isn’t always simple. Here is an explanation of the differences between c:forEach and ui:repeat, along with some examples which will hopefully save you some headaches.

TagHandlers vs Components

The most important thing to understand about the JSTL tags in JSF is that they do not represent components and never become a part of the component tree once the view has been built. Rather, they are tags which are actually responsible for building the tree in the first place. Once they have done their job they expire, are no more, cease to be, etc etc.

Here is a table of the semantics of several common tags. I just discovered, reading the Facelets code, that validators and converters are classified separately. I had always thought they were just tag handlers, but I imagine they behave in much the same way.

any custom tag file
any custom UIComponent

One of the problems here is that there is no naming convention to indicate which tags correspond to which constructs. You’ve just got to know, or find out.

When is the view built?

Now that you understand that tag handlers are only effective when the tree is built, the next logical question should be well, when is tree built?

The short answer is that a new view is built for every request which is not a postback. During a postback, the view is reconstructed from saved state. Quite confusing, and not very obvious I know, but there you have it.

Common laments

The most common pitfalls are either with the JSF lifecycle, EL evaluation or combining tag handlers with components.

My c:if always evaluates to false

<h:dataTable values="${numbers}" var="number">
    <c:if test="${number > 5}">
      <h:outputText value="${number}"/>

Yes, the c:if is always evaluating to false! But it is only ever evaluated once – when the tree is built. The h:outputText component never makes it into the tree. Solution: replace the c:if with:

<ui:fragment rendered="${number > 5}"> ... </ui:fragment>

You could also use the rendered attribute on the h:outputText component in this example.

My ui:include fails inside ui:repeat

<ui:repeat value="#{bean.items}" var="item">
   <ui:include src="#{item.src}"/>

The EL for the ui:include is evaluated when the view is built and is invalid since it relies on a variable only made available by the ui:repeat during rendering. Use c:forEach in this case.

My recursive tag never stops

  <ui:repeat value="${item.children} var="child">
    <li><eg:myTag item="${child}"/></li>

The stop condition in this recursion is supposed to be when you run out of children. The problem is that the custom eg:myTag is just a tag handler, like a special version of ui:include. When the view is built, the ui:repeat has no influence on the building process and can’t stop the recursion. Use c:forEach here instead of ui:repeat. Or better still, convert your tag file to a real UIComponent.

You might also recognise that the ${child} EL expression is meaningless during build time in this example, unless you use c:foreach.

My list doesn’t change size after deleting or adding an item

  <c:forEach items="${list}" var="item">
    <h:outputText value="${}"/><br/>
  <h:commandButton value="Create new item" action="..."/>
  <h:commandButton value="Delete an item" action="..."/>

When your view was built you only had, say, 5 items. If you post back to this view and add or delete an item, your view still has 5 h:outputText components in it since it was restored from saved state. In this simple case, you should use ui:repeat and your tree will always contain one h:ouputText component which is iterated over with differing values of ${item}.

If you rely on using c:forEach to dynamically include different form components you could run into difficulty. Always try to think about what the resulting tree looks like and remember it doesn’t change on a postback.

Suggestions for the future

Probably the best relief to this problem would be to come up with a better syntax or naming convention to distinguish between tag handlers and components. I imagine you could also improve compilation performance if you did this.

Secondly, we need better terminology. I’ve used the terms tag handler and component in this blog which isn’t too bad. The Facelets’ FAQ [1] uses the terms build-time tags and render-time tags which is a bit misleading because render-time tags (components) are involved in all phases of the JSF lifecycle, not just the Render View phase.

Whatever happens, tag handlers are very useful (would you use facelets without ui:decorate?) so let’s not get rid of them.



DIY Arduino Smartwatch

DIY Arduino Smartwatch


In one of my earlier articles, I wrote about how I made an Arduino digital watch. It showed date and time. But we want more. In this article, I’m going to add a Bluetooth module to the digital watch and link it with my phone. In this tutorial we’ll see how to link up the Arduino with your smartphone using a Bluetooth module and use it along with an android app.

So without further ado, lets roll up our sleeves and dive straight into the process!

Components Needed

1. Arduino Uno


2. Breaboard


3. 0.96” OLED Display


4. HM-05 Bluetooth module


5. 1kΩ resistors (x3)


6. Jumper wires

7. Android smartphone

Wiring Diagram

First we connect the 5v power and ground pins of the Arduino to the power and ground rails of the breadboard. The new hook up the OLED to power and ground, and connect the other pins to their respective digital pins in the Arduino board as per the diagram. Then we hook up the Bluetooth module to power and ground. Also we build the voltage divider circuit using the three 1k resistors in the receive pin of the Bluetooth module. We connect the transmit and receive pins of the Bluetooth module to the Arduino as per the diagram.

The circuit diagram drawn with the help of Fritzing


Assembled on the breadboard


How it works

We will create an android app for our smartphone using MIT’s App Inventor. It is a website where you can sign up for free and create android apps by dragging and using blocks of code. It can be used to create powerful apps even if you have no prior experience in app making.

The app we will make will search for the Bluetooth module and we can connect out phone to it. Once connected, the app will make the phone send strings of data to the Arduino, via Bluetooth. This string of data includes the time and date of the current instant, and if there is any incoming call or text at that instant, it transmits that information too.

The arduino receives this information and we can display it in the OLED screen.

Software – The App Part


(MIT’s App Inventor)

We make a quick app with MIT’s App Inventor 2. You can sign in with your Google account and start making apps by dragging and dropping components. I have shown the code used to achieve this.

First in the designer section,add two buttons – one to scan and one to connect. Add a textView to show the status of connection and a ListView to show all the available bluetooth devices in range.


Next in the code section, we write the logic. That is to define how the data is sent to the arduino. We add some non visible components such as Clock, BluetoothLE, PhoneNotification and TextNotification and Notifier components in the designer section. These components helps us to tap into the functionalities of the phone such as the clock and its bluetooth. Each item has its own different functions predefined. We just have to drag and drop the components we need to get a logical string of code. Now we define the code.




Actually you can do it however you want. In this version, we create a global string named command string and it contains the information of the date, time and phone and text notifications. We pass this string to the bluetooth, to be transmitted to the arduino to which we have connected the phone.

Software – The Arduino Code

Now that we’ve made the app to transmit the data from the phone to the Arduino once connected, let us write the code for Arduino to enable it to receive this data and print out the useful information onto our OLED screen. This is the code which was used to achieve this. We make the arduino listen for the data sent by the phone. This is done using the bluetooth module and we use the AltSoftSerial library for achieving this. You can you any library of your choice to make you version of the bluetooth module work.

#include <AltSoftSerial.h>

AltSoftSerial ASSserial; 


Adafruit_SSD1306 oled;

int pwm = 3; 

void setup() {



void loop() {

 if (ASSserial.available())
   String myTime = ASSserial.readStringUntil('|');;

    String myDate = ASSserial.readStringUntil('\n');;
    String myPhone = ASSserial.readStringUntil('\n');
    if(myTime.indexOf('time') >= 0)
      oled.print("Error - Data not Recieved");

    if(myDate.indexOf('date') >=0)
      oled.println("Data not reecieved");
      oled.print(myDate );
    if(myPhone.indexOf('phone') >= 0)
      digitalWrite(pwm, LOW);

    // Motor Vibration Pattern
    digitalWrite(pwm, HIGH);
    digitalWrite(pwm, LOW);





After uploading the code to the arduino and running the app in your smartphone, you can search for bluetooth devices and connect to the bluetooth module. Once you have done so, the OLED display will be displaying the time and date set in the phone and it will update itself automatically. The time will be displayed like so –


Also whenever a person calls you in the phone, the OLED displays an alerts you of the call. I added some more code to display the name of the contact on the OLED. Usually the non visible component for the phone sends only the phone number of the incoming call.


This alert will stay for as long as the call is ringing and it will return back to showing the time and after that.

For further modifications, you can also add a small vibrating motor and make it vibrate when the call notification is displayed. This can be done wt h a few lines of code and will be really useful when you condense this project into a small package.

For the actual use of this as a smartwatch, first you need to replace the Arduino Uno with an Arduino ProMini or even better, a standalone Atmega328p surface mount chip. For power, include a 3.7v LiPo (Lithium Polymer) battery. Make an enclosure of suitable size, most preferably 3D printed, solder all the components together, and voila, you have created your own smartwatch!

References and Resources

  1. Tinkernut’s Make a smartwatch from an old Cell Phone
  2. MIT’s App Inventor 2 – Make your own apps!

3.The AltSoftSerial for using Bluetooth modules with Arduino

Image Source – Self ( Wiring diagram made with Fritzing)


Đặc điểm của một lập trình viên 10x, 20x

Chúng ta đều đã nghe về cụm từ kỹ sư 10x, phải không? Bạn có biết rằng nghiên cứu trong những năm 1960 thực sự từng đề cập đến 20 sự khác biệt giữa một kỹ sư giỏi và tồi tệ? Cuộc thí nghiệm so sánh thời gian viết code, debug, tốc độ chạy chương trình, kích thước code… Kết quả là có tới 10 sự khác biệt nhưng theo cá nhân tôi nghĩ rằng sự khác biệt thậm chí có thể lên tới 20 đối với các kỹ sư thực sự tuyệt vời và tôi sẽ giải thích lý do tại sao trong bài viết này.

Lưu ý rằng sự khác biệt này trở nên quan trọng hơn nếu sản phẩm của bạn thành công và có thể mở rộng. Bạn có thể tuyển 20 kỹ sư dở để làm việc với những đoạn code tốt nhất, nhưng họ vẫn sẽ không đạt được những gì tuyệt vời nhất có thể.

Đã có rất nhiều bài báo liệt kê 10 điểm nổi bật của một kỹ sư giỏi, nhưng tôi vẫn sẽ nói lại cho bạn biết nhằm có sự đồng nhất. Đương nhiên, đây là ý kiến ​​cá nhân của tôi, và bạn có thể không đồng ý, nhưng mục tiêu cuối cùng vẫn là cung cấp cho các kỹ sư một số quan điểm để suy nghĩ về các lĩnh vực họ có thể cải thiện và có thể tạo sự khác biệt.

Từ 10x đến 20x

10 đặc điểm của một developer giỏi – developer 10x

1) code đơn giản, rõ ràng, dễ bảo trì và có thể mở rộng

Tôi nghĩ rằng đây là một trong những đặc điểm cơ bản. Lập trình là một nghề mà nhiều người làm việc trên cùng một project. Vì vậy, mà một developer giỏi là khi họ viết code với mục đích có thể dễ dàng được tái cấu trúc, tái cơ cấu hoặc thay thế.

2) Hiểu rõ về vấn đề gặp phải

Các kỹ sư 10x giải quyết vấn đề trực tiếp chứ không phải là đưa ra một cái nhìn chung chung tổng quát. Đây là một điểm thường bị đánh giá thấp và bỏ qua bởi nhiều người.

3) Khả năng cân bằng giữa thực dụng và cầu toàn

Các kỹ sư 10x có khả năng tạo ra cả hai giải pháp nhanh chóng và mạnh mẽ và sự khôn ngoan để lựa chọn cái nào phù hợp với một vấn đề nhất định. Họ biết khi nào nên hack và khi nào đầu tư vào chất lượng, và họ thực hiện những lựa chọn này một cách có chủ ý. Nhưng hacks của họ vẫn được viết theo cách mà họ dễ dàng ổn định sau này.

4) Sự khiêm tốn, kiên trì và tự cải thiện

Họ biết bản thân vẫn còn nhiều thứ không biết, nhưng vẫn thử làm. Sau đó, họ lặp lại bằng nỗ lực của mình cho đến khi thật sự hiểu. Kỹ sư giỏi là người luôn học tập liên tục. Họ học ngôn ngữ, công cụ, thư viện và cả cách lập trình. Tài năng của họ xuất phát từ tư duy rèn luyện liên tục. Nhờ đó, tất cả kiến ​​thức của họ mang lại cho bản thân những quan điểm khác nhau.

5) Không “ngán” bất nhiệm vụ được giao nào

Developer thường không thích debug, ngay cả khi đó là code của họ. Trái ngược lại, các developer giỏi sẽ tập trung và sửa những lỗi đó bằng sự kiên trì. Hiểu rằng điều này có thể không làm cho họ hạnh phúc, nhưng developer biết nó cần phải được thực hiện và đó là một phần trách nhiệm của mình.

6) Sử dụng công cụ hoặc phương pháp đúng cho dự án

Bất cứ công việc nào được đưa ra, các kỹ sư 10x luôn biết cách chọn đúng công cụ. Điều này thực sự có nghĩa là sự đơn giản của giải pháp quan trọng hơn việc tìm ra giải pháp dễ dàng. Họ cũng không nhất thiết phải luôn tuân theo bất kỳ phương pháp nào, nhưng họ vẫn sẽ tìm hiểu về chúng trong trường hợp chúng có thể hữu ích.

7) Biết nghi ngờ khi cần thiết

Các lập trình viên bình thường sẽ luôn bằng lòng mỗi khi tìm thấy giải pháp để làm việc. Trái ngược lại, các kỹ sư 10x có xu hướng không tin vào code của mình. Vì thế, họ sẽ kiểm tra nó kĩ lưỡng. Một sự khác biệt nhỏ, vô hại mà các lập trình viên khác có thể bỏ qua thì ngược lại developer 10x sẽ nghi ngờ nó đến từ một vấn đề lớn hơn và sẽ điều tra thêm.

8) Giỏi quản lý thời gian và công việc

Kỹ sư 10x có độ tin cậy cao bởi họ có một tinh thần làm việc mạnh mẽ và luôn xuất hiện tại các cuộc họp đúng giờ. Sự hiểu biết của họ về quản lý thời gian thực sự giúp ích trong ước tính thời điểm phát hành sản phẩm.

9) Kỹ năng giao tiếp tuyệt vời

Kỹ sư 10x có thể hiểu rõ vấn đề một cách rõ ràng và chuyển tiếp sự hiểu biết của họ cho bất kỳ thành viên nào trong nhóm. Họ cũng không cần phải có tất cả các thông số kỹ thuật được viết ra.

10) Thái độ tích cực

Họ là những người tích cực, sẵn sàng đi xa để hoàn thành công việc và cống hiến hết mình cho nó mỗi ngày. Khi bạn cần ship một bản phát hành trước deadline, họ sẽ tăng cường và đưa sản phẩm ra mắt bất cứ khi nào có thể. Bởi vì một lập trình viên giỏi là người quan tâm tới sản phẩm của mình

Các đặc điểm của developer 20x

Developer 20x có tất cả 10 đặc điểm đầu tiên của một developer 10x và cộng thêm một số kĩ năng khác!

11) Không có sự thiên vị

Các kỹ sư 20x có kỹ năng bẩm sinh để xem những gì thực sự cần thiết. Họ không ngần ngại đặt câu hỏi chất vấn về sự hiểu biết của mình và team. Đây cũng là một phẩm chất thường thấy ở product manager giỏi!

12) Không chỉ là một thành viên

Họ cải thiện team của mình thông qua sự hiểu biết, kiến ​​thức và cố vấn của mình. Họ rất vui khi thấy mọi người chịu học hỏi. Vì vậy, mà các developer 20x luôn ủng hộ lập trình cặp, không phải vì họ muốn cố vấn bạn, nhưng bởi vì họ cảm thấy bản thân cũng có thể học hỏi. Vì vậy mà tư duy của developer 20x dần được ủng hộ và làm theo bởi các thành viên khác trong nhóm.

13) Giỏi giao tiếp và ứng biến với Client/Sếp

Kỹ sư 20x rất giỏi trong việc giao tiếp với khách hàng hoặc manager của họ. Nhờ đó mà developer hiểu được các vấn đề tiềm ẩn vốn không rõ ràng trong tiềm thức của khách hàng / sếp và đưa ra các giải pháp phù hợp. Thông thường, điều này sẽ mang lại lợi ích năng suất rất lớn cho các đồng nghiệp của họ nhờ vào cái nhìn sâu sắc của developer 20x.

14) Cân bằng trong công việc và cuộc sống

Developer 20x hiểu rằng bất kỳ dự án nào đều là một cuộc chạy marathon chứ không phải chạy nước rút. Điều này có nghĩa là họ cố gắng cho đồng đội có thể về nhà vào cuối ngày. Các developer 20x có xu hướng để cho những đồng nghiệp ít kinh nghiệm hơn có được giữ sự cân bằng hợp lý giữa làm và chơi.

15) Cái nhìn toàn diện về sản phẩm

Các developer 20x xem cách mọi người sử dụng phần mềm của họ, tìm hiểu điều gì khiến user thất vọng và sau đó đưa ra cách để cải thiện nó. Nói cách khác, developer 20x không đưa ra giả định về những gì mọi người muốn từ phần mềm của mình. Thay vào đó, họ sẽ cố gắng hiểu khách hàng cũng như là tham gia vào các cuộc thảo luận về sản phẩm.

16) Hiểu rõ hơn về tình hình kinh doanh

Kỹ sư 20x có thể hiểu được các yếu tố quan trọng hơn trong phát triển phần mềm, chẳng hạn như nhu cầu đặc biệt từ khách hàng, thiết kế UI / UX, đưa ra ngân sách và hơn thế nữa. Điều này đảm bảo họ có thể đưa ra quyết định đúng đắn ở mọi bước. Developer 20x cũng có thể nghiên cứu lĩnh vực kinh doanh mà họ đang làm việc, để để giải quyết các vấn đề rộng hơn.

Sưu tầm: