[Discovery] RAID 0, RAID 1, RAID 5, RAID 10 Explained with Diagrams

RAID stands for Redundant Array of Inexpensive (Independent) Disks.

On most situations you will be using one of the following four levels of RAIDs.

  • RAID 0
  • RAID 1
  • RAID 5
  • RAID 10 (also known as RAID 1+0)

This article explains the main difference between these raid levels along with an easy to understand diagram.

In all the diagrams mentioned below:

  • A, B, C, D, E and F – represents blocks
  • p1, p2, and p3 – represents parity

RAID LEVEL 0


Following are the key points to remember for RAID level 0.

  • Minimum 2 disks.
  • Excellent performance ( as blocks are striped ).
  • No redundancy ( no mirror, no parity ).
  • Don’t use this for any critical system.

RAID LEVEL 1

Following are the key points to remember for RAID level 1.

  • Minimum 2 disks.
  • Good performance ( no striping. no parity ).
  • Excellent redundancy ( as blocks are mirrored ).

RAID LEVEL 5


Following are the key points to remember for RAID level 5.

  • Minimum 3 disks.
  • Good performance ( as blocks are striped ).
  • Good redundancy ( distributed parity ).
  • Best cost effective option providing both performance and redundancy. Use this for DB that is heavily read oriented. Write operations will be slow.

RAID LEVEL 10

Following are the key points to remember for RAID level 10.

  • Minimum 4 disks.
  • This is also called as “stripe of mirrors”
  • Excellent redundancy ( as blocks are mirrored )
  • Excellent performance ( as blocks are striped )
  • If you can afford the dollar, this is the BEST option for any mission critical applications (especially databases).

REF: http://www.thegeekstuff.com/2010/08/raid-levels-tutorial/

[Discovery] Thực hư chuyện tháp nghiêng Pisa sẽ đổ trong tương lai?

Nhắc đến nước Ý lãng mạn, chúng ta khó có thể quên được một di tích nổi tiếng – tháp nghiêng Pisa. Tuy nhiên ít ai biết được rằng, tháp nghiêng Pisa liên tục “chao đảo” trong suốt 840 năm kể từ ngày khởi công đầu tiên.

Tháp nghiêng Pisa đã từng “nghiêng ngửa” như thế nào?

Trên thực tế, tòa tháp huyền thoại này đã bắt đầu nghiêng từ những năm 1173, khi mới chỉ vẻn vẹn 3 tầng được xây. Nguyên nhân được cho là vật liệu làm móng của tháp có mật độ không ổn định. Vì lý do này mà tháp bị nghiêng về phía Bắc. Để khắc phục tình trạng này, ngay từ những ngày đầu, các nhân công đã quyết định “bù” lại độ nghiêng của tháp bằng cách xây cột và mái vòm ở tầng 3 cao hơn một chút về phía bị nghiêng. Tầng thứ 4 của tháp nghiêng Pisa cũng được xây dựng ngay sau đó.

Từ năm 1173 trở đi, tháp nghiêng Pisa vẫn lắc lư trong suốt 100 năm. Nhưng sự việc không chỉ dừng lại ở đó, khi mà móng tháp bị xẹp xuống không đồng đều. Vào năm 1272, tháp Pisa thậm chí còn “nghiêng về phía nam”. Một lần nữa, các kỹ sư lại quyết định “bổn cũ soạn lại” – xây dựng tầng thứ 5 để bù độ nghiêng của tháp. Sau 1 thời gian cải tạo, đến năm 1278, công trường xây dựng tháp Pisa lại bị bỏ dang dở với chỉ 7 tầng xây xong.

Đầu thế kỉ 14 là thời kì mà tháp nghiêng Pisa đã thật sự đứng giữa ranh giới “kì quan” và “phế liệu”. Thấp 1 lần nữa lại chao đảo và lần này độ nghiêng đã đạt tới mức báo động đỏ. Có lẽ vì tiếc công sức trong 300 năm vừa qua nên các kiến trúc sư quyết tâm cải tổ lần cuối cùng tháp nghiêng Pisa. Dự án sau cùng cũng được hoàn thiện vào giữa năm 1360 – 1370, với việc bổ sung thêm chiếc chuông khổng lồ trên tầng 8 tháp nghiêng Pisa.

Tưởng như tháp nghiêng Pisa có thể đi vào hoạt động ổn định sau khi hoàn thiện. tuy nhiên cho đến cuối thế kỉ 16, sau sự kiện Galileo Gallilei thả viên đạn đại bác từ đỉnh tháp xuống, người ta vô tình đã biết được tháp bị nghiêng 3 độ so với phương thẳng đứng. Đến năm 1911, các kiến trúc sư vô tình phát hiện ra một sự thật gây chấn động toàn nước Ý: Đỉnh tháp Pisa nghiêng từng 1.2 mm 1 năm.

Vào năm 1935, các kỹ sư xây dựng đã củng cố lại móng của tháp Pisa. Công việc đã được tiến hành bằng cách đổ hỗn hợp xi măng vào mạng lưới các lỗ được đào ở dưới móng. Rất đáng tiếc vì đây là 1 tính toán sai lầm của các kỹ sư, khi mà việc này lại vô tình “đốn” tháp nghiêng Pisa khiến nó sập nhanh hơn. Rất may là hàng loạt các biện pháp gia cố đã được thực thi kịp thời, trước khi “kì quan thế giới hiện tại” bị biến thành 1 đống gạch vụn thật sự.

Vào năm 1989, có một công trình tương tự như tháp nghiêng Pisa được tiến hành xây dựng nhưng ít người biết đến là tháp nghiêng Pavia. Sở dĩ ít người biết là do “tháp nghiêng Pavia” sau khi xây xong chỉ còn là 1 đống đổ nát.

Việc này khiến các quan chức Italia lo sợ trước nguy cơ thành tựu hàng trăm năm bị đổ xuống sông xuống biển, trong khi ngày lễ ra mắt công chúng đang gần kề. Một liên minh các kỹ sư hàng đầu từ các quốc gia được thành lập nhằm “cứu vớt” tháp nghiêng Pisa. Sau cùng, liên minh cũng đồng ý với phương án của John Burland – chuyên gia về các vật liệu cơ học – với phương án rút bớt đất ở phần móng phía bắc tháp Pisa. Việc này đã được tiến hành trong vòng vài năm.
Khi dự án hoàn thành vào năm 2001, “liên minh cứu hộ tháp nghiêng Pisa” đã kéo được tòa tháp khổng lồ dựng thẳng đứng lên 44 cm. Đây là kết quả khiến các chính trị gia rất hài lòng và tự tin đưa vào hoạt động. Kết quả còn tuyệt vời hơn nữa khi mà đến tận tháng 5 năm 2008, các cảm biến theo dõi không phát hiện được thêm bất cứ một cm bị xê dịch nào của tháp nghiêng Pisa.

Liệu nước Ý có thể “kê cao gối ngủ” trước vấn đề nghiêng của tháp Pisa?

Dự án của John Burland giữ tháp Pisa “thẳng đứng” nếu xét trên góc độ “lý thuyết”. Thực tế còn một vấn đề rất đáng lo ngại là các tầng của tháp nghiêng Pisa có dấu hiệu giảm chất lượng theo thời gian. Thậm chí chỉ một trận động đất nhỏ cũng có thể khiến một trong các tầng của tháp Pisa sụp đổ dễ dàng. Tuy nhiên theo ước tính của các kỹ sư xây dựng, tháp nghiêng Pisa sẽ còn đứng vững được trong ít nhất 200 năm nữa. Thêm vào đó, với trình độ khoa học kỹ thuật hiện đại, tháp nghiêng Pisa sẽ có thể được tăng thêm ít nhất … 800 năm tuổi thọ. Chắc hẳn người dân Italy sẽ không khoanh tay đứng nhìn di tích hàng nghìn năm của tổ tiên bị thời gian hủy hoại.

Tham khảo: Howstuffworks

[Dev Tip] Compare two objects

Sometime, you need to compare objects. Beside of override the Equal(), GetHashCode() methods, which are for some domain rules.

If you must compare all properties of the object, then I suggest another way to get it done: using JSON.

You can serialize those objects and compare JSON results.


public static void AreEqualByJson(object expected, object actual, string message = "")
{
var settings = new JsonSerializerSettings
{
PreserveReferencesHandling = PreserveReferencesHandling.All
};

var expectedJson = JsonConvert.SerializeObject(expected, settings);
var actualJson = JsonConvert.SerializeObject(actual, settings);
Assert.AreEqual(expectedJson, actualJson, message);
}

[Dev Tip] The GetHashCode() and Equals() in the implemented IEqualityComparer interface

When you compare two objects using an EqualityComparer then the IEqualityComparer.Equals and IEqualityComparer.GetHashCode methods are used instead of the methods on the Key objects.

# Recall

Every object in .NET has an Equals method and a GetHashCode method.

The Equals method is used to compare one object with another object – to see if the two objects are equivalent.

The GetHashCode method generates a 32-bit integer representation of the object. Since there is no limit to how much information an object can contain, certain hash codes are shared by multiple objects – so the hash code is not necessarily unique.

A dictionary is a really cool data structure that trades a higher memory footprint in return for (more or less) constant costs for Add/Remove/Get operations. It is a poor choice for iterating over though. Internally, a dictionary contains an array of buckets, where values can be stored. When you add a Key and Value to a dictionary, the GetHashCode method is called on the Key. The hashcode returned is used to determine the index of the bucket in which the Key/Value pair should be stored.

When you want to access the Value, you pass in the Key again. The GetHashCode method is called on the Key, and the bucket containing the Value is located.

# Example

BoxEqualityComparer boxEqC = new BoxEqualityComparer(); 

Dictionary<Box, String> boxes = new Dictionary<Box, string>(boxEqC); 

Box redBox = new Box(100, 100, 25);
Box blueBox = new Box(1000, 1000, 25);

boxes.Add(redBox, "red"); 
boxes.Add(blueBox, "blue"); 

[Photograph] Choáng ngợp trước vẻ đẹp của những địa danh nổi tiếng từ góc nhìn trên cao

Nhóm AirPano bao gồm những thành viên ưa thích du lịch mạo hiểm đã thực hiện một chuyến đi vòng quanh thế giới và chụp lại những bức ảnh vô cùng ấn tượng từ góc nhìn trên cao. Họ đã sử dụng một chiếc máy bay để có thể chụp lại những địa danh nổi tiếng trên thế giới, những nơi mà họ đã từng đi qua. Danh sách những địa danh này dự kiến ở con số 100, tuy nhiên nhóm AirPano cho biết họ sẽ còn tiếp tục những chuyến đi của mình.

Những bức ảnh của nhóm AirPano bao gồm cả những địa danh tự nhiên như những thác nước hay các đỉnh núi, cũng như cả những thành phố lớn trên thế giới như New York hay Dubai, và có cả Vịnh Hạ Long của chúng ta.

Những bức ảnh này cho chúng ta một cái nhìn hoàn toàn khác về những địa danh này. Nó cho chúng ta thấy sự hùng vĩ của tự nhiên cũng như của những công trình do con người xây nên.

Chúng ta hãy cùng chiêm ngưỡng những bức ảnh ấn tượng nhất trong bộ ảnh của nhóm AirPano:

Thành phố Dubai.

Thành phố Dubai.

Thác nước Falls Angel ở Venezuela.

Thác nước Angel ở Venezuela.

Nhà thờ Sagrada Familia tại thành phố Barcelona.

Nhà thờ Sagrada Familia tại thành phố Barcelona.

Thác nước Falls Victoria tại Zambia.

Thác nước Victoria tại Zambia.

Thác nước Iguasu tuyệt đẹp tại Argentina.

Thác nước Iguasu tuyệt đẹp tại Argentina.

Đỉnh núi Everest.

Đỉnh núi Everest.

Khải hoàn môn tại nước Pháp.

Khải hoàn môn tại nước Pháp.

Tòa nhà Empire State tại thành phố Manhattan.

Tòa nhà Empire State tại thành phố Manhattan.

Miệng núi lửa Plosky Tolbachik tại Nga.

Miệng núi lửa Plosky Tolbachik tại Nga.

Một góc thành phố Manhattan.

Một góc thành phố Manhattan.

Bờ biển Barrier Reef tại Úc.

Bờ biển Barrier Reef tại Úc.

Taj Mahal tại Ấn Độ.

Ngôi đền Taj Mahal tại Ấn Độ.

Vịnh Hạ Long của Việt Nam.

Vịnh Hạ Long của Việt Nam.

Những tảng băng nổi trên bờ biển của Iceland.

Những tảng băng nổi trên bờ biển của Iceland.

Toàn lâu đài Neuschwanstein tại Đức.

Toàn lâu đài Neuschwanstein tại Đức.

Kim tự tháp tại Ai Cập.

Kim tự tháp tại Ai Cập.

Thành phố Singapore nhìn từ trên cao.

Thành phố Singapore nhìn từ trên cao.

[Dev Rule] 11 Rules All Programmers Should Live By

I am a person who tends to live by rules.

Now granted, they are mostly rules I set for myself—but they are still rules.

I find that creating rules for myself helps me to function better, because I pre-decide things ahead of time instead of making all kinds of decisions on the fly.

Should I go to the gym this morning?

Well, my rule says that on Wednesdays I go to the gym and today is Wednesday, so I am going to the gym—that settles it.

This week, as I was thinking about some of the kinds of rules I impose on myself, I thought it might be a good idea to come up with a set of rules that I think all software developers should live by.

Now, I’ll admit, most of these rules are more of guidelines, but anyway, here they are:

1: Technology is how you get to the solution, it is not THE solution

We can get really carried away with the latest JavaScript framework—ahem, Angular—IoC container, programming language or even operating system, but all of these things are not actually solutions to the problems we are trying to solve as programmers, instead they are simply tools that help us solve the problems.

We have to be very careful not to get too crazy about a particular technology that we happen to like or that happens to be oh so popular right now, lest we run the risk of thinking about every problem as a nail, just because we happen to be holding a shiny hammer we just learned about.

2: Clever is the enemy of clear

When writing code, we should strive to write code that is clear and easy to understand.

Code that clearly communicates its purpose is much more valuable than code that is obscure—no matter how clever it may be.

It’s not always true, but in general, clever is the enemy of clear.

It’s usually true that when we write code that is “clever,” that code isn’t particularly clear.

It’s important to remember this rule whenever we think we are doing something particularly clever.

Sometimes we write clever code that is also clear, but usually that is not the case.

If you’re interested in writing clean code I highly recommend you check out The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin)

code

3: Only write code if you absolutely have to

This one might seem a little contradictory, after all, isn’t our job as programmers to write code?

Well, yes and no.

Our jobs may involve writing code, but we should still strive to write as little of it as possible to solve the problem we are trying to solve.

This doesn’t mean we should make our code as compact as possible and name all our variables using single letters of the alphabet. What it does mean is that we should try to only write code that is actually necessary to implement the functionality that is required.

Often it is tempting to add all kinds of cool features to our code or to make our code “robust” and “flexible” so that it can handle all different kinds of situations. But, more often than not, when we try to guess about what features would be useful or we try to pave the road to solve for problems that we think might exist in the future, we are wrong.

This extra code may not add any value, but it can still do a lot of harm. The more code there is, the more chances for bugs and the more code that has to be maintained over time.

Good software engineers don’t write code unless it’s absolutely necessary.

Great software engineers delete as much code as possible.

4: Comments are mostly evil

I’m not a big fan of writing comments in code. I’m with Bob Martin, when he says:

“Every time you write a comment, you should grimace and feel the failure of your ability of expression.”

Clean Code: A Handbook of Agile Software Craftmanship

This doesn’t mean that you should never write comments, but for the most part they can be avoided and instead you can focus on doing a better job of naming things.

Comments should only really be written when it’s not possible to clearly communicate the intent of a variable or method by using a name. The comment then serves an actual purpose that could not be easily expressed in the code.

For example, a comment could tell you that this strange order in which some operation was occurring in the code was not a mistake, but was intentional because of a bug in the underlying operating system.

In general though, comments are not only evil because in many cases they are necessary, but also because they lie.

Comments don’t tend to get updated with the rest of the code and this results in the comments actually becoming dangerous, because they very well could steer you in a completely wrong direction.

Do you check every single comment against the code to make sure the code is actually doing what the comment says? If so, what is the point of having the comment? If not, how can you trust that the comment is telling you the truth?

It’s a pickle, so it’s best to avoid it as much as possible.

Ok, haters, go ahead and leave your torrent of “comments” in the comment section below, but I’m not changing my stance on this one.

5: Always know what your code is supposed to do before you start writing it

It seems obvious, but it isn’t.

How many times have you sat down to write code without fully understanding what the code you were writing was actually supposed to do?

I’ve done it more times than I’d like to admit, so this is a rule that I need to read often.

Practicing test driven development (TDD) can help here, because you literally have to know what the code is going to do before you write it, but it still doesn’t stop you from creating the wrong thing, so it’s still important to make sure you absolutely, 100% understand the requirements of the feature or functionality you are building before you build it.

6: Test your sh—code before you ship it

Don’t just toss your code over the wall and have QA pound on it only to send it back to you so that you can waste a bunch of everyone’s time with unnecessary bug reports and resolutions.

Instead, take a few minutes to run through the test scenarios yourself, before you call your code done.

Sure, you won’t catch every bug before you pass your work on to QA, but you’ll at least catch some of the stupid and embarrassing mistakes that we all make from time-to-time.

Too many software developers think that it is only QA’s job to test their stuff. It’s simply not true. Quality is everyone’s responsibility.

Stack of open books

 7: Learn something new every day

If you didn’t learn something new today, you just made backwards progress, because I can guarantee you forgot something.

It doesn’t take a lot of time to learn something new each and every day.

Try spending just 15 minutes or so reading a book—I read a whole lot of books last year, just reading about 45 minutes each day on average.

The little advances you make each and every day add up over time and will greatly shape your future. But, you have to start investing now if you want to reap the rewards later.

Besides, today technology is changing so rapidly that if you aren’t continually improving your skills and learning new ones, you are going to be left behind very quickly.

8: Writing code is fun

That’s right. You probably didn’t get into this profession just because it pays well.

I mean, there is nothing wrong with picking a job that pays well, but doctor or lawyer would have probably been a better choice.

Most likely you became a software developer, because you love writing code. So, don’t forget that you are doing what you love.

Writing code is a lot of fun. I wish I could write more code.

I’m usually too busy keeping this business going to spend much time writing code these days, which is one of the reasons why I so clearly remember how much fun it is.

Perhaps you forgot that writing code is fun. Perhaps it’s time to remember how much fun it is again, by starting a side project or just changing your mindset and realizing that you get to write code and you are even paid for it. (Hopefully)

9: You can’t know it all

As much as you learn, there is still going to be a lot you don’t know.

It’s important to realize this because you can drive yourself nuts trying to know everything.

It’s OK to not have all the answers.

It’s OK to ask for help or to speak up when you don’t understand something.

In many cases, you can learn what you need to know pretty darn close to when you need to know it—believe me, I do it all the time.

My point is, don’t get caught up in trying to learn it all, when that is an impossible task. Instead, focus on learning what you need to know and building the skills that enable you to learn things quickly.

10: Best practices are context dependent

Is test-driven development, the best way to write code?

Should we always pair program?

Are you a scrub if you don’t use IoC containers?

The answer to all of these questions is “it depends.”

It depends on the context.

People will try to shove best practices down your throat and they’ll try to tell you that they always apply—that you should always do this or that—but, it’s simply not true.

I follow a lot of best practices when I am writing code, but I also conditionally don’t follow them as well.

Principles are timeless, best practices will always be situational.

11: Always strive to simplify

All problems can be broken down.

The most elegant solutions are often the most simple ones.

But, simplicity doesn’t come easy. It takes work to make things simple.

The purpose of this blog is to take some of the complexities of software development, and life in general, and make them simple.

Believe me, this isn’t an easy task.

Any fool can create a complex solution to a problem. It takes extra effort and care to refine a solution to make it simple, but still correct.

Take the time. Put forth the effort. Strive for simplicity.

[Discovery] Chất điện phân mới giúp loại bỏ sự hình thành của sợi dendrite gây đoản mạch pin Li-ion

Dendrite. Hình ảnh hiển vi cho thấy chất điện phân thông thường tạo điều kiện cho sợi dendrite phát triển (hình a) trong khi chất điện phân của PNNL khiến Lithium hình thành dạng nốt nhỏ, không gây đoản mạch(hình b).

Dendrite là một loại sợi dẫn điện mỏng thường hình thành bên trong pin Lithium khiến cell pin giảm tuổi thọ và là tác nhân gây cháy nổ. Mới đây các nhà khoa học tại phòng thí nghiệm quốc gia tây bắc Thái Bình Dương (PNNL) thuộc bộ năng lượng Hoa Kỳ đã công bố họ đã tạo ra một chất điện phân mới cho pin Lithium với khả năng không chỉ loại bỏ hoàn toàn sợi dendrite mà còn hứa hẹn tăng hiệu suất sử dụng pin và cải thiện dung lượng.

Rất nhiều loại pin sạc sử dụng trên các thiết bị di động hiện nay dùng công nghệ Li-ion – gồm 2 điện cực, 1 cực dương bằng Lithium, 1 cực âm bằng graphite (than chì) và dùng chất điện phân hóa học. Về cơ bản, chất điện phân chứa các electron mang điện và đóng vai trò trung gian truyền tải dòng điện giữa các điện cực khi pin được nối vào một mạch điện. Khi xả pin, Lithium rời khỏi bề mặt cực dương và bám vào cực âm, ngược lại khi sạc pin, Lithium kết tụ trở lại trên cực dương. Qua thời gian sạc/xả, bề mặt cực dương hình thành các sợi dendrite và các sợi này sẽ mọc dài hơn khi Lithium liên tục lắng đọng.
Các sợi dendrite phá vỡ đường dẫn điện tích thông thường và tạo ra các đường dẫn lộn xộn xuyên suốt cấu trúc pin. Một khi sợi dendrite mọc đủ dài, xuyên qua lớp điện phân và kết nối trực tiếp cực âm với cực dương thì pin sẽ bị đoản mạch.

Kết quả là pin tự xả không thể kiểm soát làm giảm tuổi thọ pin. Ngoài ra, sợi dendrite còn khiến pin nóng lên, gây phản ứng tỏa nhiệt và phát nổ dù đang để ở ngoài hay bên trong thiết bị di động.

Sợi dendrite mọc rất nhanh từ cực dương và chạm đến cực âm.

Để ngăn ngừa sự hình thành của sợi dendrite, một số nhà nghiên cứu đã thử nghiệm một số giải pháp như bổ sung một lớp phủ chứa các quả cầu carbon cho cực dương của pin hoặc điều chỉnh công thức chất điện phân với một số phụ gia hay thậm chí là cho thêm sợi nano Kevlar vào hỗn hợp này. Tuy nhiên, sợi dendrite thì vẫn cứ mọc mà không có dấu hiệu bị hạn chế.

Chất điện phân mới được PNNL phát triển nhắm đến mục tiêu thay thế hoàn toàn chất điện phân đang được sử dụng trên pin Li-ion bởi nó không tạo điều kiện cho sợi dendrite hình thành. Thêm vào đó, nó cũng tăng dung lượng và hiệu năng của pin.

Tiến sĩ Ji-Guang “Jason” Zhang đến từ PNNL cho biết: “Chất điện phân mới của chúng tôi giúp tăng 99% hiệu suất của pin Li-ion và nâng mật độ dòng điện lên 10 lần so với công nghệ trước. Phát hiện mới của chúng tôi có thể khởi động quá trình phát triển các thế hệ pin sạc tiếp theo hữu dụng và mạnh mẽ hơn chẳng hạn như pin Lithium-lưu huỳnh (Li-sulfur), pin Lithium-khí và Lithium-kim loại.”

Dựa trên một nghiên cứu cho thấy các chất điện phân chứa nồng độ muối cao có thể cản trở sự thình thành của sợi dendrite, tiến sĩ Zhang cùng các cộng sự đã sử dụng một lượng lớn muối Lithium bis(fluorosulfony)imide, một hợp chất silicon hữu cơ và dung môi dimethoxyethaein để tạo ra chất điện phân.
Dendrite_01.

Hình ảnh hiển vi cho thấy các sợi dendrite mọc dài trong pin Li-ion.

Để thử nghiệm hỗn hợp mới, nhóm nghiên cứu đã tạo ra một cell pin hình tròn có đường kính dưới 25 mm. Khi cell được sạc, thay vì các sợi dendrite xuất hiện và mọc dài ra, điện cực Lithium lại sản sinh một tấm mỏng có các nốt Lithium nhỏ trên bề mặt và chúng không tác động được đến chất điện phân gây đoản mạch pin.

Nhóm sau đó tiếp tục thí nghiệm cell pin với hơn 1000 chu kỳ sạc/xả và cho biết cell vẫn duy trì được 98,4% điện tích ban đầu và mật độ dòng điện khoảng 4 mA/cm2. Khi thay đổi mật độ dòng điện, hiệu suất của pin cũng bị tác động. Theo đó nếu duy trì mật độ 10 mA/cm2 thì hiệu suất của pin đạt xấp xỉ 97% trong khi nếu giữ mật độ 0,2 mA/cm2 thì hiệu suất tích điện của pin có thể đạt đến 99,1%.

Theo các nhà nghiên cứu, đây là những con số rất ấn tượng bởi phần lớn pin Li-ion thông thường với các cực bằng Lithium hoạt động ở mật độ dòng điện khoảng dưới 1 mAh/cm2 và thường hỏng sau chưa đầy 300 chu kỳ sạc/xả.

Ngoài việc tăng hiệu suất, chất điện phân mới cũng được cho là có thể mở đường cho một thiết kế mới trong công nghệ pin – được gọi là cell pin không có cực dương. Nói cách khác, bản thân chất điện phân có thể đóng vai trò của một điện cực. Thiết kế thực tế của loại cell này chắc chắn sẽ cần được tinh chỉnh nhưng với một chất điện phân hoạt động với trên 99% hiệu suất thì các nhà nghiên cứu đang đứng trước một cơ hội để tạo ra một loại pin chỉ có thành phần tích lũy dòng điện tích trái dấu mà không cần đến một vật liệu phản ứng phủ trên cực dương. Việc loại bỏ cực dương cũng giúp giảm chi phí, kích thước và cải thiện độ an toàn của pin sạc.

Dĩ nhiên chất điện phân mới của PNNL vẫn cần trải qua nhiều thử nghiệm và hiệu chỉnh trước khi được thương mại hóa. Zhang cùng các cộng sự đang tiếp tục mở rộng nghiên cứu với nhiều phụ gia khác để cải tiến chất điện phân nhằm đạt được hiệu suất 99,9% – điều kiện tiên quyết để sản xuất thương mại và phát hành trên thị trường.

Nguồn: PNNL

[Discovery] Làm thế nào giáo sư Stephen Hawking có thể sống sót hơn 50 năm qua với hội chứng ALS?

Tinhte-stephen-hawking-ai.Stephen Hawking được mệnh danh là ông hoàng vật lý của thế giới hiện đại. Khi nhắc tới ông, người ta thường nghĩ ngay tới bức xạ Hawking, Định lý kỳ dị, Lược sử thời gian cùng vô vàn những cống hiến vĩ đại đã góp phần không nhỏ cho sự phát triển của vật lý và thiên văn học ngày nay. Tuy nhiên, khuôn khổ bài viết này chúng ta sẽ không nói về tri thức của ông, mà tìm hiểu về nghị lực sống phi thường của ông. Làm thế nào một người đàn ông nhỏ bé có thể tiếp tục sống trong hơn 50 năm với căn bệnh ALS, vốn bị các bác sĩ kết luận rằng chỉ có thể kéo dài từ 2 đến 3 năm.

Stephen Hawking – bệnh nhân phi thường

Vào ngày 20/4/2009, nhiều thập kỷ sau lời tiên đoán ảm đạm của các bác sĩ, bệnh tình của giáo sư Hawking bắt đầu trở nặng. Khi đó, trường Đại học Cambridge đã phát đi thông báo rằng tình hình của giáo sư là “rất yếu” và “phải trải qua các thử nghiệm” tại bệnh viện. Thậm chí, các tờ nhật báo còn đưa tin và chuẩn bị sẵn cáo phó dành cho giáo sư Hawking.

Nhưng cuối cùng, ông vẫn sống sót. Chẳng những thế, lúc đó chẳng có ai dám nghĩ rằng ông sẽ sống tới 73 tuổi như hiện nay, vẫn ngồi trên chiếc xe lăn chuyên dụng đưa ra lời cảnh báo về sự diệt vong của nhân loại vì AI và thậm chí là xem bộ phim tiểu sử của chính ông. Nhưng kỳ lạ thay, ông đã thực hiện tất cả những điều đó và còn hơn thế nữa.

Tinhte-stephen-hawking-2007. Ảnh chụp giáo sư Stephen Hawking vào năm 2007

Chứng bệnh mà Stephen Hawking mắc phải là xơ cứng cột bên teo cơ (Amyotrophic Lateral Sclerosis – ALS hoặc Lou Gehrig) và chúng ta khó lòng có thể tưởng tượng được những hậu quả mà nó để lại cho ông. Triệu chứng đầu tiên của nó là khiến cho cơ bắp của người mắc yếu dần đi và cuối cùng là liệt hoàn toàn. Điều này xảy ra trên khắp cơ thể và lấy đi khả năng nói chuyện, nuốt và thậm chí là thở của người bệnh. Hiệp hội ALS thống kê rằng tuổi thọ trung bình của những người mắc bệnh chỉ vào khoảng từ 2 đến 5 năm kể từ thời điểm phát bệnh. Hơn 50% số người bệnh qua đời trong năm thứ 3 và 20% sống được tới năm thứ 5. Chỉ có khoảng 5% người bệnh sống được qua 2 thập kỷ.

Và đối với giáo sư Hawking, ông đã vượt qua được giới hạn 20 năm tới 2 lần, mốc đầu tiên vào năm 1983 và sau đó là năm 2003. Cuối cùng cho đến ngày hôm nay, năm 2015, ông vẫn tiếp tục sống. Khả năng kéo dài sự sống một cáhc thần kỳ của ông khiến các chuyên gia nghiên cứu bệnh ALS phải khâm phục và cho rằng ông là một trong những trường hợp ngoại lệ duy nhất.

Nigel Leigh, giáo sư thân kinh học lâm sàng tại Đại học King, London phát biểu: “Ông là một trường hợp phi thường. Tôi chưa từng biết có người nào sống sót được với căn bệnh ALS trong thời gian dài như ông. Ngoài thời gian sinh tồn thì đối với trường hợp của Hawking, dường như căn bệnh của ông đã bị đẩy lùi. Ông ấy vẫn đang tương đối ổn định – một dạng ổn định cực kỳ hiếm thấy.”

Không phải sức sống kỳ diệu của Hawking mới được chú ý gần đây mà nó đã dấy lên làn sóng hiếu kỳ từ giới nghiên cứu từ hơn 10 năm trước. Vào thời điêm Hawking bước sang tuổi 70 vào năm 2012, nhiều nhà khoa học đã tỏ ra đầy bối rối và kinh ngạc. Nhà nghiên cứu Anmar al-Chalabi tại Đại học Kinh đã phải thốt lên rằng: “Thật phi thường. Tôi chưa bao giờ thấy ai có thể sống sót trong thời gian dài như vậy.”

Giả thuyết về nguyên nhân

Vậy thật sự điều gì cho phép trường hợp của Hawking vượt trội hơn so với những bệnh nhân khác? Chỉ dựa vào may mắn? Phải chăng ông đã dùng trí tuệ siêu phàm để dùng một cách nào đó giúp kéo dài sự sống và chống lại định mệnh? Không ai có thể trả lời chắc chắn. Ngay cả chính bản thân Hawking, người có thể lý giải cơ chế hoạt động của toàn vũ trụ, cũng không thể xác định được nguyên nhân của sự sống của ông. Ông nói: “Có thể loại bệnh ALS của tôi có liên quan khả năng hấp thu vitamin kém.”

Tinhte-stephen-hawking-giang. Giáo sư Hawking và bài phát biểu “Tại sao chúng ta nên tiến vào không gian?” tại Địa học George Washington vào năm 2008

Các nhà khoa học cho rằng ngay từ đầu, Hawking đã chiến đấu với ALS bằng một cách rất khác. Và rất có thể, những khác biệt này đã tạo nên sự sống dài kỳ lạ của ông. Thông thường, ALS sẽ tấn công người bệnh vào khoảng nửa cuối cuộc đời, trung bình là khoảng 55 tuổi. Nhưng các triệu chứng của ALS lại xuất hiện trên cơ thể Hawking từ khi ông còn rất trẻ. Và đặc biệt hơn, nó bắt đầu bằng một cú ngã.

Giáo sư Hawking đã hồi tưởng lại: “Vào năm thứ 3 tại Oxford, tôi nhận thấy rằng mình bắt đầu vụng về và tôi đã ngã xuống từ 1 đến 2 lần mà không có lý do. Nhưng mãi cho đến khi tôi đến Cambridge thì cha tôi mới nhận thấy và đưa tôi đến bác sĩ. Không lâu sau sinh nhật lần thứ 21 của tôi, ông giới thiệu cho tôi một chuyên gia và tôi đã phải vào viện đê thực hiện các xét nghiệm. Đó thật sự là một cú sốc đối với tôi khi phát hiện ra mình mắc bệnh.”

Dù vậy, các nhà nghiên cứu cho rằng nhờ những chẩn đoán từ rất sớm mà Hawking đã có cơ hội sống cùng với căn bệnh lâu hơn so với những người khác. Giáo sư Leigh cho biết: “Chúng tôi nhận thấy rằng cơ hội sống sót của những bệnh nhân trẻ là nhiều hơn và cuộc sống cũng được kéo dài hơn. Nếu bạn phát bệnh khi còn trẻ, con quái vật bệnh tật sẽ rất khác, rất kỳ quặc và không ai biết lý do tại sao.”

Nhà nghiên cứu Leo McCluskey tại Đại học Pennysylvania cho biết ALS có thể lấy đi mạng sống của bệnh nhân theo 2 cách khác nhau. Thứ nhất, nó khiến cho cơ bắp có liên quan tới hoạt động thở bị tê liệt và thông thường người bệnh sẽ chết vì suy hô hấp. Con đường còn lại là cơ điều khiển hành động nuốt bị liệt, khiến cơ thể bị mất nước và suy dinh dưỡng. “Nếu bạn không lâm vào cả 2 dạng trên, bạn có khả năng sẽ sống trong một thời gian dài.”

Nhưng liệu trường hợp của Hawking còn có khác biệt nào khác? Về phần mình, Hawking cho rằng sự tập trung vào công việc đã phần nào giúp ông vượt qua được tình trạng tàn tật và cho ông thêm những năm tháng sống sót mà những người khác không có được. Giáo sư Hawking chia sẻ: “Chắc chắn công việc và sự chăm sóc tận tình đã giúp tôi tồn tại. Tôi rất may mắn khi công tác trong lĩnh vực vật lý lý thuyết, một trong những lĩnh vực hiếm hoi không bị ảnh hưởng bởi sự khuyết tật.”

Dù sao đi nữa, chúng ta phải thật sự khâm phục những gì mà ông đã làm cho sự phát triển của khoa học dù phải ngồi trên chiếc xe lăn. Ông thật sự đã đối mặt với muôn vàn khó khăn trong cuộc sống cũng như công việc. Hy vọng rằng ông vẫn sẽ mạnh khỏe và tiếp tục cống hiến cho khoa học trong tương lai.

Tham khảo SA, Nytimes, NCBI, NBC

[Dev Tip] Burrow.Net – web pages

I have to note some pages which has talked about the Burrow.net and RabbitMQ. I will play with them later.

http://thoai-nguyen.blogspot.com/2012/05/messaging-rabbitmq-and-burrownet.html

http://thoai-nguyen.blogspot.com/2012/06/custom-burrownet-tunnelfactory-rabbitmq.html

http://thoai-nguyen.blogspot.com/2012/06/things-you-can-change-in-burrownet.html

http://thoai-nguyen.blogspot.com/2012/06/programmatically-rabbitmq-exchange.html

http://thoai-nguyen.blogspot.com/2014/06/using-rabbitmq-header-exchange-with.html

http://thoai-nguyen.blogspot.com/2013/07/monitor-rabbitmq-queues-count-message.html

http://thoai-nguyen.blogspot.com/2012/10/rpc-with-burrownet-and-rabbitmq.html

And: https://github.com/vanthoainguyen/Burrow.NET