Hành trang trẻ


Trị hôi chân
Tháng Bảy 22, 2011, 5:42 sáng
Filed under: Uncategorized

Củ cải trắng

Dùng nửa củ cải trắng, cắt thành lát mỏng, cho vào nồi, đổ lượng nước vừa đủ. Để lửa to đun sôi trong 3 phút, sau đó ninh lửa nhỏ trong 5 phút, rồi đổ ra chậu, đợi cho nguội bớt, cho chân vào ngâm rửa. Ngâm rửa trong vài ngày liên tục có thể khử sạch mùi hôi.

Muối+gừng

Cho lượng muối vừa đủ, vài lát gừng tươi vào nước đun sôi, để nguội bớt rồi ngâm rửa chân trong vài phút. Cách này không chỉ giúp khử mùi hôi, mà còn có thể tiêu trừ mệt nhọc, đem lại cảm giác thoải mái, dễ chịu.

Đậu nành

Dùng 150g đậu nành, 1 lít nước, đun với lửa nhỏ trong 20 phút, để nước đủ ấm dùng ngâm chân. Cách này trị mùi hôi chân rất hiệu quả, lại giúp bảo vệ da chân. Thông thường ngâm rửa liên tục 3-4 ngày sẽ thấy công hiệu.

Lá sung

Lấy vài lá sung đun với nước trong khoảng 10 phút, đợi nước đủ ấm, dùng ngâm chân trong 10 phút. Mỗi ngày 2 lần, thông thường 3-5 ngày sẽ hết mùi hôi.

Dấm

Có thể dùng bông tẩm dấm bôi lên chân có mùi hôi, có tác dụng trị ngứa và diệt khuẩn. Những chỗ hơi bị bong da, có thể bôi một lần giữ được trong nửa tháng. Khi bị lại, lại tiếp tục bôi như vậy.

Bia

Đổ 1 chai bia vào chậu nước, cho nước vừa đủ. Rửa sạch chân, sau đó cho vào chậu nước bia ngâm rửa trong 20 phút, rồi rửa sạch lại. Mỗi tuần làm 1-2 lần.

Tỏi tây

Rửa sạch 250g tỏi tây, giã nát cho vào chậu nước, đổ nước sôi vừa đủ. Đợi nước đủ ấm, ngâm chân trong nửa tiếng. Một tuần ngâm rửa 1 lần, có tác dụng rất tốt.

Lô hội

Ngày hè, dùng chất nhờn từ lá lô hội xoa lên vùng chân có mùi hôi, rồi để khô tự nhiên có tác dụng trị mùi hôi rất tốt. Mỗi lần dùng 1 lá cho 1 chân.

Vỏ lê

Dùng vỏ lê xoa trực tiếp lên vùng chân có mùi hôi cũng có công dụng khử mùi.

Phèn chua

Tán phèn chua thành bột, xoa lên lòng bàn chân trong 10 phút. Làm liên tục khoảng 3-4 ngày chân sẽ không bị ra mồ hôi gây mùi khó chịu. Cách này có thể giữ trong 7-8 tháng không bị lại.



An Embedded Software Primer
Tháng Hai 22, 2008, 4:09 sáng
Filed under: Lập trình | Thẻ: , ,

Download

http://rapidshare.com/files/93857479/An_Embedded_Software_Primer.zip.html



Kinh nghiệm viết thư xin việc
Tháng Mười Một 19, 2007, 1:16 chiều
Filed under: Sự nghiệp | Thẻ: , , ,

1. Nếu bạn không biết chắc chắn tên và giới tính của người bạn muốn gởi thư xin việc thì tốt hơn hết nên để chung chung là Dear Hiring Manager – “Kính gởi ban quản lý nhân sự”. Không được để Dear Sir or Madam – “Kính gởi ông hoặc bà”.

2. Nếu bạn biết chắc chắn học vị của họ thì sử dụng lời chào cùng học vị, ví dụ Dr – “Tiến sĩ”.

Nếu bạn biết tên, hãy ghi cả tên một cách trịnh trọng. Kính gởi Tiến sĩ Smith – “Dear Dr. Smith”

3. Nếu bạn biết chắc chắn đó là phụ nữ, nhưng không biết cô ta có bằng học vị gì hay không, thì sử dụng lời chào là “Ms”. Hoặc cả tên: Kính gửi cô Jones – “Dear Ms. Jones”.

4. Không sử dụng quá nhiều Miss (người phụ nữ chưa lập gia đình) hay Mrs (người phụ nữ đã lập gia đình). Nếu bạn không biết họ có gia đình hay chưa thì nên dùng Ms (chỉ người phụ nữ có hoặc chưa có chồng).

5. Nếu bạn biết chắc đó là nam, nhưng bạn không biết họ có học vị gì hay không, thì nên sử dụng lời chào Mr “Ngài”. Kính gửi Ngài Jones – “Dear Mr. Jones”.

6. Nếu bạn không biết họ là nam hay nữ, thì sử dụng cả tên và họ của người ấy. Kính gửi Pat Jones – “Dear Pat Jones”.

Vì sao? Vì người đàn ông cũng có thể được đặt những cái tên hơi nữ tính như là Lynn, Tracy, hay Marion còn người phụ nữ cũng có thể được đặt những cái tên hơi nam tính như Devon, Jamie hay Morgan. Khi bạn còn mơ hồ thì tốt hơn nên dùng cả tên và họ của họ.

Nếu bạn sử dụng đúng tên, giới tính, địa vị của nhà tuyển dụng trong thư xin việc, thế thì còn gì tuyệt hơn. Điều đó chứng tỏ bạn am hiểu và quan tâm đến họ cũng như vị trí bạn ứng tuyển. Đó là một khởi đầu tốt đẹp hứa hẹn cho cuộc gọi phỏng vấn trực tiếp.

Theo HRvietnam



Cách đọc sách hiệu quả
Tháng Mười Một 16, 2007, 5:52 chiều
Filed under: SoftSkill | Thẻ: , , ,

1. Tạo sự tập trung cho chính mình bằng cách xem lướt qua bài đọc trước khi bạn thật sự ngồi đọc từng chữ:
Xem tựa đề bài đọc, các tiêu đề lớn nhỏ, những chỗ đánh dấu, in nghiêng hoặc in đậm.

Xem qua những hình vẽ hay minh họa, đồ thị hay biểu đồ.

Xem qua toàn bộ bài đọc bằng cách đọc đoạn đầu và đoạn cuối, lướt nhanh qua những câu đầu của từng đoạn trong bài (trường hợp sách giáo khoa về kinh tế thường có phần tóm tắt ở cuối mỗi chương cùng những thuật ngữ quan trọng).

Gấp sách lại và tự hỏi: ý chính của bài là gì, văn phong ra sao và mục đích của tác giả là gì?

Trả lời được những câu hỏi này sẽ phần nào giúp các bạn có được một ý tưởng khái quát về nội dung bài đọc, từ đó dễ tập trung hơn và bài đọc sẽ trở nên dễ nhớ hơn.

2. Không đọc thành tiếng

Vì kiểu đọc này sẽ khiến bạn đọc chậm. Cố gắng xem việc đọc sách như thể đang ngắm một cảnh đẹp, hình dung một ý tưởng bao quát trong tâm trí thay vì chú ý đến từng viên đá dưới chân.

3. Đọc theo ý.

Các nghiên cứu cho thấy khi đọc, mắt chúng ta luôn dừng sau những câu chữ trong một dòng. Số lần dừng của người đọc chậm nhiều hơn so với người đọc nhanh. Dừng nhiều lần không chỉ làm cho ta đọc chậm mà còn cản trở khả năng nắm bắt vấn đề, do ý nghĩa thường đi theo cả câu hay cụm từ thay vì từng chữ một. Hãy cố đọc theo những nhóm từ, đặc biệt đọc hết những câu hoàn chỉnh và những câu có tính bổ nghĩa.

4. Không nên đọc một câu nhiều lần.

Đây là thói quen của người đọc kém. Thói quen “nhai lại” này thường làm tăng gấp đôi hoặc gấp ba thời gian đọc và cũng không cải thiện mức độ thông đạt. Tốt nhất là cố tập trung ngay từ lần đầu tiên, đó là lý do tại sao chúng ta có gợi ý thứ nhất.

5. Thay đổi tốc độ đọc

Việc này giúp thích ứng với độ khó và cách viết trong bài đọc. Người đọc kém luôn có tốc độ đọc chậm. Người đọc hiệu quả thường đọc nhanh phần dễ và chậm lại ở phần khó. Trong một bài đọc có đôi chỗ chúng ta phải đọc cẩn thận hơn những chỗ khác. Có những điều được viết ra không phải để đọc thoáng. Với những tài liệu pháp lý hay các bài viết khó thì cần phải đọc chậm. Những tài liệu dễ hơn như kinh tế hay báo chí thì ta có thể đọc nhanh.



Phương pháp làm việc thế nào là khoa học
Tháng Mười Một 6, 2007, 7:13 sáng
Filed under: Uncategorized | Thẻ: , , ,

Phương pháp làm việc thế nào là khoa học, hiệu quả chất lượng? Bạn đã bao giờ nghe tới PDRI?

Có bao giờ bạn tự hỏi, mình đã đang và sẽ làm gì tiếp theo nhỉ? Khi đứng trước bất kỳ vấn đề, bất kỳ công việc nào, bất kỳ lĩnh vực nào, chắc hẳn nhiều khi bạn sẽ bối rối, không biết bắt đầu thế nào.Vậy bạn hãy tập cho mình và cùng thuyết phục nhóm làm việc, tổ chức của bạn, dù một chút ít thôi, hãy áp dụng công thức PDRI, ở đâu đó người ta sử dụng PDCA. Cụ thể chúng là gì? Tại sao chúng được coi là nguyên tắc vàng trong công việc và được coi là một trong những phương pháp làm việc khoa học và phổ biến nhất trên thế giới?

PDRI là viết tắt của các từ tiếng Anh: Plan – Do – Review – Improve; còn PDCA là viết tắt của các từ: Plan – Do – Check – Act.

Bạn có thể lặp lại PDRI cho tất cả các pha trong triển khai công việc của bạn

Trong Plan (Kế hoạch) bạn giả quyết các vấn đề của gọi nôm na là 4 bà mới có 1 ông để đảm bảo giải quyết các mục tiêu của bạn (goals): – What: làm những gì nhỉ? – Who: ai làm gì? – Where: làm ở đâu nhỉ? – When: làm khi nào nhỉ? – How: làm thế nào đây?

Trong Do: Bạn thử nhìn lại mình, nhóm làm việc của mình, công ty mình! Bạn cớ làm, cứ làm (Do, do, and do) và bạn chợt nhận ra chẳng bao giờ kết thúc được cái việc đang làm cả, vì chẳng có cái Plan nào cả.

Nhiều người thất bại khi lập Plan, thất bại nhiều hơn khi Do (Execute) và thất bại hoàn toàn khi Review (measure – Xem lại chẳng làm được gì thành công) và thảm hại hơn khi chúng ta không dành lấy một chút ít thời gian để nhìn lại rút kinh nghiệm với nhau, để hỏi tại sao ta thất bại.

Kể cả khi thành công, tại sao ta không xem xét lại ta có thể làm tốt hơn được nữa không?

Tóm lại, bạn hay than phiền, ông chủ của bạn “Vắt chanh bỏ vỏ”, theo tôi không hẳn thế, nếu bạn làm việc một cách khoa học, chỉ cần áp dụng PDRI, bản thân bạn sẽ trưởng thành theo thời gian với mỗi công việc, dự án bản đảm nhiệm. Hay nói cách khác, bạn học, tiến bộ và trưởng thành qua công việc. Nếu không có thời điểm nhìn lại mình, bạn thấy mình thật đơn điệu, nhàm chán, không còn hứng thú và sức sống, khả năng làm việc và cống hiến của bạn không còn nữa. Ôi, lúc đó thật là chán, kể cả lúc đó bạn đã rất thành công, rất nhiều tiền, và bạn đã nắm những chức vụ rất lớn. Bạn vẫn thấy mình thật chán.

Có thể hơi mang tính nghề nghiệp một chút, khi nói đến quy trình trong công việc. Khi nhắc đến CMM hay ISO trong công nghiệp phần mềm, người ta cũng đề cập đến. Đó là mỗi người, mỗi nhóm làm việc, mỗi công ty, khi làm bất kỳ công việc hay dự án gì, nếu chúng ta tuân thủ các phương pháp làm việc theo các mức (level) sau, thế là chúng ta đã tự mình lập chuẩn cho mình rồi:

1/ Documented: Ghi nhận lại thành dạng tài liệu, dù bất kỳ tài liệu dạng gì, biểu mẫu có chuẩn hay không, không quan trọng, quan trọng là được ghi lại. => thế là ta đã ở chuẩn 1 rồi, hihi!

2/ Defined: Việc bạn, nhóm của bạn, thành viên trong nhóm, làm việc gì, việc đó đã được định nghĩa rõ ra là việc gì, bạn có thể gọi tên được nó. => chuẩn 2 rồi nhé!

3/ Repeated: có dạng công việc nào đó, modul nào đó, quy trình nào đó, nhóm, bạn có thể lặp lại, tái sử dụng, bạn gom lại chau chuốt lại, áp dụng lại được. => thế mà là chuẩn 3 rồi đấy!

4/ Risk Plan & Mgt: Nếu ngay từ khi lập kế hoạch, chỉ cần bạn, nhóm của bạn có tính đến khả năng rủi ro của công việc, dự án. Tốt rối, nếu bạn tính được cả phương án phòng ngừa và chống đỡ nếu lỡ nó xảy ra, thật là tuyệt vời phải không. Bạn đã ở chuẩn 4 rồi đấy! Hêhê!

5/ Optimized Decision: Sau nhiều chuỗi ngày làm việc và làm việc, đột nhiên bạn nhìn lại và thấy rằng, nếu trước khi đến đoạn này, hoặc trước khi làm việc này, dự án này. ta rút kinh nghiệm dự án khác, công đoạn trước, … ta tối ưu nó, kết quả tốt hơn thật. Nếu đã làm việc này, bạn đã ở chuẩn 5 rồi đấy!

Bạn đã bao giờ tự hỏi, tại sao bất kỳ công ty, tổ chức nào cũng phải bắt buộc có Kế toán và Thủ quỹ là 2 người khác nhau?

Bạn phải công nhận một điều là chính bạn và kể cả và nhất là các ông Sếp của bạn ghét làm việc theo quy trình. Tại sao vậy?

– Cứng nhắc quá, mất thời gian quá, phiền hà quá, rườm rà quá, nhiều tài liệu phải làm quá

– Sếp không trực tiếp can thiệp vào chỗ mình muốn xử lý trực tiếp, lại cứ phải đợi chạy qua đủ các công đoạn các bước, …

Đây không phải riêng bạn hay Sếp của bạn ngại áp dụng quy trình trong công việc. Theo quan điểm riêng tôi, tôi lập trình ra một ứng dụng phần mềm, nghĩa là tôi đã giúp ai đó giảm thiểu sức lao động, công việc nhàm chán và bắt máy tính làm việc thay con ngưới. Thì với một tổ chức, một doanh nghiệp, quy trình công việc chính là công cụ tốt nhất giúp ông ta lập trình cho hoạt động của công ty ông ta. Chỗ nào tự động, chỗ nào lặp, chỗ nào input, output, bộ phận phòng ban nào làm cái gì trước, cái gì sau, việc gì là bắt buộc phải thực hiện trước việc gì, … đó chính là quy trình. Một ông Sếp chỉ quản lý doanh nghiệp của mình bằng quy trình: đó là bộ máy của ông ta, ông ta không thể nhớ hết mọi tên, mặt của tất cả mọi nhân viên trong cơ quan, nhưng ông ta biết doanh nghiệp mình có các bộ phận nào, các trưởng bộ phận ấy là ai, key man trong bộ phần ấy là ai (nếu sâu sát).

Bạn đã bao giờ chán sử dụng một phần mềm này mà thích phần mềm khác, chắc chắn có. Mình cần xử lý vài cái lặt vặt, nó cứ bắt mình khai báo vàthao tác bao nhiêu bước. Bực thật! Thì bạn, ông Sếp của bạn ghét dùng quy trình là vì bạn, ông Sếp của bạn đã phải dùng một phần mềm “củ chuối” là cái quy trình cứng nhắc, khó chịu phải tuân theo; đó là sản phẩm tồi của những người tư vấn, lập ra nó và khong bao giờ cải tiến để phù hợp với thực tiễn.

Quy trình bản thân nó không cứng nhắc, nó cũng có tính mở, tính khả chuyển, nó sẽ tốt hơn nếu các mục tiêu, đối tượng, giá trị được phân lớp mịn và tốt. Công việc cấp nào, độ quan trong và khẩn cấp cỡ nào thì Sếp trực tiếp giải quyết, v.v.v còn nếu đã có tiền lệ, hãy để nó automatic!

Tham khảo:

http://www.pqu.uts.edu.au/planning_quality_management_uts/pdri_cycle.html

https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/deploym…

http://www.ecu.edu.au/equ/pdri.html



Các công cụ lập trình cho Java (Java IDE)
Tháng Mười Một 2, 2007, 10:21 sáng
Filed under: Lập trình | Thẻ: , ,

IDE Showdown - Evangelists duke it out at Cologne JUG

July 2007

Discuss this Article

On July 3rd, the Cologne JUG conducted an IDE shootout that included Maxim Shafirov, Mike Aizatsky, and Ann Oreshnikova from JetBrains, Roman Strobl from NetBeans, Wayne Beaton from the Eclipse Foundation, and Frank Nimphius of Oracle. Each of the four groups were given 30 minutes to show off their wares. This gave all that attended the opportunity to see each of the IDEs in action in a head-to-head format.

Netbeans

First up was Sun’s Roman Strobl. Strobl intermixed a small set of slides with a number of live demos. First up was a demonstration of an application built in NetBeans that imported Google maps. The application demonstrated that NetBeans is more than just an IDE. It is a platform capable of hosting some very interesting applications: NetBeans, the IDE being the most famous of them. From this demonstration Strobl moved into a quick demonstration of different features found in NetBeans (the IDE).

The list includes Matisse, the NetBeans GUI builder, the profiler, and support for JRuby development. Strobl used a music CD cataloging application to demonstrate how to use Matisse to build a GUI. In the demonstration, Strobl added a slider to the window and then, using their implementation of the new Beans Binding specification, bound the slider to a rating column found in the pre-existing database. The profiling demo focused on how one would use the profiling capabilities to diagnose and correct a memory leak. The two features focused on were generations and heapwalker. Generations was used to help determine which object was leaking. Heapwalker is a way to trace the chain of references from an object back to its roots.

Time prevented Strobl from demonstrating mobility support. He instead moved on to create a crude blogging application. The application was built in about 3 minutes using Rails (and a little help from some templates). Strobl wanted to demonstrate the use of a voice manager API written in Java in the blog application. Unfortunately the final demo failed at the buzzer but it was nonetheless a great demonstration of JRuby support in NetBeans.

The Eclipse Foundation

Next up was Wayne Beaton from the Eclipse Foundation. Getting the Eclipse Foundation to participate in this event was one of the more difficult challenges for the organizers of this event. The first few minutes of Beaton’s talk focused on the source of some of these challenges. The Eclipse Foundation isn’t only about Eclipse the IDE, it is about Eclipse the platform that is used by many in the Eclipse eco-system to create some very interesting and unexpected applications.

“It [Eclipse] wasn’t intended to be an IDE, it was intended to be an open source framework to solve problems,” said Beaton.

In the presentation, Beaton threw up a logo cloud that demonstrated just how large and diverse the Eclipse ecosystem is. It is an environment where many competitors have come together to cooperate and contribute to Eclipse. These competitors then build on top of Eclipse to complete.

First up, after the introduction, was a demonstration of the open source reporting application, BIRT (Business Intelligence Reporting Tool). Other interesting applications built on top of the Eclipse Rich Client Platform where control systems used by NASA Jet Propulsion Laboratory (JPL). One application built by the JPL was used to control the Mars lander. In terms of developer support there is plug-in support for C/C++, Ruby, JavaScript and even boutique languages such as Scheme and Smalltalk.

Other technologies integrated into Eclipse included the SOA Tools Platform, TopLink (Eclipse Blade), DLTK (Dynamic Languages Toolkit for Eclipse Platform) which includes the capability to create language aware editors from a grammar and DSCP for small embedded device development.

In the last half of the talk, Beaton focused on Mylyn, included in a newly made available download from www.eclipse.org. Most projects contain a significant amount of code. This point is demonstrated via a Calendar application that Beaton has written on top of Eclipse RCP. Mylyn allows you to build tasks and focus the development environment on those tasks. It works to remove clutter from your view so that you see only those things that you care about. If you return to an older task, Mylyn will work to re-expose those elements that have become important.

Oracle JDeveloper

Frank Nimphius, the Principle Product Manager for Oracle JDeveloper started his talk with a short history of Oracle development tools. He then spoke of how JDeveloper has evolved from some source code purchased from Borland into what it is today. He also addressed the significant contributions that Oracle has made to Eclipse. In doing so he provided an answer to the question, “Why would Oracle continue with JDeveloper?”

To answer this question Nimphius explained how Oracle not only produces technology but also consumes technology. JDeveloper has an important user base within Oracle and is seen as a key to the technology that is produced. To satisfy the needs of these consumers it made sense to continue JDeveloper development. He also pointed out that Oracle contributes quite a bit to the Eclipse Foundation and then answered a question he posed, “Why doesn’t Oracle drop JDeveloper in favor of Eclipse?” The reason is that with so many consumers of Oracle technology, with their varying requirements, it made sense to continue on with JDeveloper. According to Nimphius, Oracle committed to ensuring that the market place has a strong alternative choice in an IDE.

As would be expected from a database company, JDeveloper comes with a lot of support for Java/database integration activities. This includes the capability to create schemas and edit data. They also wanted to ensure that application developers, no matter what skill level they’re at, would be productive in the IDE. This included Forms developers that really had no idea of what Java is.

“(Our aim is to) help everybody, the coder, the Java EE specialist, and help newbies and also our 4GL type customers that are working with Oracle forms that are used to drag and drop and have no clue what Java really is,” Nimphius said. “Now have these guys become productive immediately.”

Nimphius acknowledged the high level of copying that occurs between each of the IDEs. Features that appear in one will appear in the others tomorrow so these features are no longer the key to an IDE’s future. What *is* key are secondary feature sets and for

JDeveloper this translates to full life-cycle support.

Two JSRs that Oracle is involved in include JSR 198, the plug-in specification and JSR 227, Standard Binding and Data Access Facilities for JEE. The reference implementation for JSR 227, known as Oracle Application Development Framework, creates an abstraction layer between the UI and the business logic layer.

Nimphius’s demo was to build an EJB 3.0 application using ADF bindings with an AJAX component. JDeveloper supports developer interactions at all levels, from those that like to tinker under the hood to those that just want to use the interactions without everybody looking at them. Another interesting feature is support for reusable task fragments. The example given was for login logic. The demo ended with Nimphius adding in some very nice data bindings with support for some AJAX interactions.

IntelliJ IDEA

JetBrains rounded out the night with a talk about IntelliJ IDEA. Notably, IDEA was the only IDE that cost money so it seemed a reasonable start that Aizatsky addressed the question of why should someone pay money for their IDE. The biggest reason given was that the JetBrains development team listens to you, the developer. The next question Aizatsky addressed was why IntelliJ isn’t open source.

“Open source is all about the opportunity to contribute back to the project,” said Aizatsky. “But honestly, how many people have ever produced a custom build of Eclipse? I think no one, no one here (at least).”

When the same comment was made about a patch for Eclipse, Beaton suggested that Aizatsky look into the bug database. Though Aizatsky took the point, the essence of his argument still remains: IDEs are complex applications and like any other complex application it isn’t something that anyone can jump into and easily contribute to. Aizatsky’s claim that with IntelliJ’s early access program (EAP) they had found a more efficient way for users to contribute back to the project.

The EAP provides a forum in which IDEA users are able to contribute back thoughts, report on bugs and offer feature suggestions. Once more, everyone at JetBrains is committed to listening to those that contribute, Aizatsky said. In one instance this even led them to delay a GA release.

IDEA has long been known for its innovations in IDE technology and this presentation was quick to point out a number of them. The list of innovations discussed included:

1) Automatic creation of important statements
2) Refactoring even with code that will not compile
3) Syntax based selections (Intelli-sense)
4) Parameter shortcuts
5) High-lighting of compile time errors
6) Implementation of refactoring
7) Static code analysis (beyond compiling)
8) Camel hump navigation
9) Langauge APIs
10) Support for injected langauges (even in Java literals). The short demo that followed the slides focused on a number of innovations that went beyond what the compiler will tell you.

These innovations included not-null analysis to awareness of variable names and how to assist developers when the IDE believes that you are using the wrong variable.

Strobl stirred things up a bit by showing a code generation feature in NetBeans that looked identical to one found in IntelliJ (there was a difference in shadowing). It was a demonstration that brought about annoyed looks of frustration from the IntelliJ group.

During the Q&A that followed the sessions, Beaton re-iterated the point brought up by Aizatsky during his presentation. From his perspective, IDE users are interested in seeing about 80% of the features in all IDEs and so it made sense that all IDEs work about the same way. It was the secondary set of features on which they should be competing. Thus we see a lot of cooperation not only in the Eclipse Foundation but even between the IDE authors themselves. Strobl mentioned an Eclipse implementation that included Matisse. Support for Toplink and the JPA soon to be included in all IDEs is sourced from Oracle.

Q&A session

The presentations were followed up with a Q&A session. Those that attended were not disappointed as each of the presenters did an excellent job representing their respective products.

However, some tough questions were asked. In many ways Eclipse is blazing its own trail and a number of questions were directed at finding out why certain technologies were chosen over “standard ones”. Though some of the decisions (bundling of Harmony) seemed politically motivated, most do have a solid technical footing. The OSGi component model currently has no match and it will be quite some time before the modules JSR will be ready.

NetBean’s “blatant copying” of IntelliJ was also questioned but this concern too was addressed from the perspective of Aizatsky and Beaton.

Other questions centered around IntelliJ’s support for Domain Specific Languages (DSL). This is an area where JetBrains is putting forth efforts to make DSL more accessible to average developers.

Taken as a whole the IDE shootout at the Cologne JUG showed how competition amongst the various IDE offerings has really helped to boost developer productivity. It also demonstrated that the commanding lead that Eclipse currently enjoys is not so safe. They need to keep innovating in order to maintain that lead as the others keep pushing forward in the market. JetBrains clearly demonstrated why they’ve earned their reputation and how they plan on keeping it. The take away from this JUG meeting is that there is still much innovation to be done in the IDE arena to better support and better enable productivity for us, the developer. Hats off to the Cologne JUG for organizing this great evening.

Biography

Kirk Pepperdine is a performance tuning specialist offering training and consulting services. He can be reached at kirk@kodewerk.com



4 cách thắt cà vạt
Tháng Mười Một 2, 2007, 10:09 sáng
Filed under: Mẹo vặt | Thẻ:

Cà vạt từ lâu đã trở thành đồ trang sức không thể thiếu của các quý ông, và gần đây, các quý cô trẻ tuổi cũng đặc biệt yêu thích thời trang sơ mi thắt cà vạt. Sau đây là 4 cách thắt cà vạt khác nhau giúp bạn luyện tập và lựa chọn.

Thông thường, cà vạt được treo ở mắc cùng với áo sơ mi, hoặc các quý ông thường có thói quen thắt sẵn cà vạt để tiện lợi hơn khi sử dụng. Tuy nhiên, những lúc đi xa hoặc đi công tác, tốt nhất là bạn nên gập cà vạt đúng cách để giữ cho cà vạt không bị nhăn hoặc bị tạo thành nếp gấp khi sử dụng.

Sau đây là cách gập cà vạt chuẩn

User Posted Image

Cách 1: Thắt kiểu Four in Hand

Đây là cách thắt đơn giản nhất với bốn động tác cơ bản và cũng là cách thắt nhanh nhất. Đặc điểm của cách thắt này là nút thắt nhỏ, chặt và bất đối xứng. Kiểu này phù hợp với cổ áo có khuy chuẩn, và cà vạt làm từ chất liệu dày.

Cách 2: Thắt kiểu Windsor

Cách thắt cà vạt này được sử dụng phổ biến vào những năm 1930 là cách phức tạp hơn và quả trám cũng to hơn. Phù hợp với cổ áo rộng, thích hợp cho những buổi phóng vấn xin việc, thuyết trình …

Cách 3: Thắt kiểu bán Windsor

Đây là cách thắt Windsor đã được đơn giản hóa. Có thể dùng với các loại áo, và các loại cà vạt bằng vải mỏng và trung bình.

Cách 4: Thắt kiểu Pratt


Cách thắt này được một người Mỹ phát minh vào năm 1989 là đóng góp cuối cùng vào nghệ thuật thắt cà-vạt. Thích hợp cho mọi loại quần áo với cà vạt từ chất vải mỏng hoặc dày tùy thích.

 

Việt Sơn – Theo Tie-aTie