[Discovery] Các nhà vật lý đề xuất mô hình mới có thể mở lỗ sâu đủ lâu cho phép 1 photon xuyên qua

lo_sau. ​


Hồi cuối tuần rồi, nhà vật lý Luke Butcher tại Đại học Cambridge đã cho đăng tải báo cáo về một số dạng mô hình lỗ sâu (wormhole) có khả năng duy trì đủ lâu để 1 photon có thể đi qua. Theo mô hình mà Butcher đề xuất thì con người hoàn toàn có thể gởi và nhận những thông điệp xuyên thời gian thông qua lỗ sâu này. Nếu mô hình này được phát triển thành công thì giấc mơ của con người về cỗ máy du hành thời gian sẽ không còn là vấn đề viễn vông nữa mà hoàn toàn có thể khả thi vào một ngày nào đó trong tương lai.

Cho đến nay, du hành thời gian là một khái niệm chỉ tồn tại trong trí tưởng tượng của các nhà văn khoa học viễn tưởng. Một số người còn gọi đây là giấc mơ giữa ban ngày trong khoa học hiện đại. Dù vậy, các nhà vật lý học tin rằng ít nhất là trong lý thuyết, du hành thời gian hoàn toàn có thể thực hiện được. Chính thiên tài vật lý Albert Einstein là người đầu tiên đề xuất khả năng du hành thời gian băng lỗ sâu – một đường hầm xuyên thời gian và không gian. Có thể hình dung đây là một con đường hầm nối thông từ một vùng không gian-thời gian này đến một vùng khác, đôi khi còn cho phép vật chất đi từ vùng này sang vùng kia thông qua đường hầm này.

Tuy nhiên, việc chế tạo một thiết bị nhằm mở lỗ sâu không hề đơn giản. Trở ngại lớn nhất là các lỗ sâu chỉ có thể tồn tại trong thời gian cực ngắn và không có đủ chỗ cho con người đi qua. Trên mặt lý thuyết, một lỗ sâu chỉ có thể cho một hạt đơn hoặc 1 photon đi xuyên qua. Chính vì thế, việc du hành thời gian là vấn đề bế tắc nhất trong vật lý hiện đại. Mãi cho tới năm 1988, nhà vật lý học Kip Thorne đã đề xuất 1 ý tưởng cho phép duy trì một lỗ sâu trong thời gian dài hơn.

Thorne cho rằng lỗ sâu có thể được duy trì độ mở bằng cách sử dụng loại năng – lượng – lượng – tử, còn gọi là năng lượng Casimir. Trong khi đây là một ý tưởng đầy hứa hẹn, nhưng cho đến nay vẫn chưa có một ai tìm ra cách tạo ra năng lượng Casimir để duy trì lỗ sâu và cho phép con người đi qua. Trong nghiên cứu lần này, Butcher đề xuất phương pháp tận dụng năng lượng Casimir trong tự nhiên để tạo nên một số loại lỗ sâu.

Sau khi thực hiện rất nhiều tính toán, Butcher đã kết luận rằng nếu lỗ sâu mở ra càng lâu thì kích thước của nó cũng sẽ càng lớn. Đồng thời ông cũng dự đoán rằng lượng năng lượng Casimir ở mặt bên trong của lỗ sâu sẽ giúp nó có đủ năng lượng để mở ra lâu hơn so với bình thường. Theo ước tính của Butcher, hoàn toàn có thể gởi một photon thông qua lỗ sâu tạo thành từ mô hình do ông đề xuất.

Dù vậy, tất cả những lập luận và nghiên cứu trên đều chỉ là giả thuyết dựa trên hiểu biết của Butcher. Con người vẫn chưa hiểu hết được các thành phần khác của lỗ sâu. Có thể bên trong lỗ sâu sẽ chứa các thành phần ngăn chặn chuyển động của photon hoặc thậm chí là ngăn chặn con người di chuyển xuyên qua. Do đó, việc du hành xuyên thời gian vẫn chỉ là một chủ đề hấp dẫn cho các nhà làm phim hay các nhà văn khoa học viễn tưởng. 

Tuy nhiên, Butcher cho rằng ý tưởng của mình sẽ thúc đẩy nhiều nghiên cứu hơn trong tương lai. Có thể sẽ có nhiều ý tưởng mới được đề xuất thực hiện. Có thể một ngày nào đó việc du hành thời gian không chỉ có thể thực hiện bởi Doctor Who trên truyền hình mà còn có thể được thực hiện trong thực tế.

[Dev tip] Git server on Windows

First of all, let me clarify that Git doesn’t need to specify the side for client and server. Your workstation can be both the client and server. That means you can get code from other computer, you’re the client; while others can also get code from your computer, you’re the server. That’s why Git is great.

In this post, the “Git server” means to make your computer available for others to pull/push code from/to.

The post is long because it’s step by step and with lots of screenshots. In fact, it just takes about 10 minutes to setup all.

Note: CopSSH is not open source any more, please buy it if you want to use it.

We need the following software:

Software required to setup a Git server:
CopSSH (install on the server side)
msysgit (install both on the server side and client side)
PuTTY (install both on the server side and client side)

Software required to integrate with Visual Studio:
GitExtensions (install both on the server side and client side)

Setup steps

1. Install msysgit.

a. When you installing the msysgit, please choose c:\Git as the installation directory, because the space in the directory name may cause issue in bash commands.
image

b. In the “Adjusting your PATH environment”, I recommend to select “Use Git Bash only”.
image

c. Other settings are default. After installation, you get the icon  on your desktop. You can try it with git command, if you get the following screen, you’ve installed the msysgit successfully.
image

d. Add C:\Git\bin and C:\Git\libexec\git-core to Path. This step is very important.
image

2. Install CopSSH

a. Just like the msysgit, we don’t install the CopSSH in program files folder to avoid some space issues. We install it toc:\ICW
image

b. Just use the default account as CopSSH provides:
image

c. After installation, open COPSSH Control Panel
image

d. Click Add button in Users tab
image

e. Choose an existed user on your computer(You can create one in computer management). Here in my sample the user is jinweijie
image

f. Allow all the access:
image

g. After the user is activated, click the Keys… button in the Activated Users section:
image

h. Click Add:
image

i. Use default key settings:
image

j. Enter the Passphrase and File name:
image

k. The private key will be save to c:\ICW\home\jinweijie\ryan-vm-01_2048.ppk
image

[test step]Now we try to use the activated user to log on through SSH, open Git Bash, enter commands:
ssh jinweijie@ryan-vm-01
enter “yes” to continue
image

[test step]After enter your passwords (the windows account’s password), then you try to run git as the ssh user, but it isn’t perform as you expected:
image
That’s because CopSSH cannot find the git.exe on the server, so we need to tell CopSSH the git path.

3. Config CopSSH with Git path.

a. Open C:\ICW\etc\profile with your favorite editor, add :/cygdrive/c/git/bin:/cygdrive/c/git/libexec/git-core (don’t forget the starting colon) to PATH ,  the whole line will be:
export PATH=”/bin:$syspath:$winpath:/cygdrive/c/git/bin:/cygdrive/c/git/libexec/git-core”
Then Save.
image

b. Restart the CopSSH by click twice the big button in CopSSH Control Panel:
image

c. If we run Git Bash again, ssh jinweijie@ryan-vm-01, enter your password and run the git command, git should be found this time:
image

4. Configure private key on client

a. Copy the private key(we generated in step 1-k) from server to client.
SNAGHTMLc1563

b. On the client side, use puttygen.exe to load the key(if you set the password in 1-j, you need to enter the password while loading the key):
image

c.  Click “Save private key” to save a copy of private key for plink.exe to recognize.
image

5. Create repository, integrate with Visual Studio

a. Install gitextensions on both server and client.
image

b. Since we have already install the msysgit in step 1-a, we skip the “Install MsysGit”. But if you haven’t install msysgit on the client machine, you can check the checkbox and install it.
image

c. Install to C:\GitExtensions\, Other settings are default.
image

d. On the server side, open Git Extensions, click “Create new repository”
image

e. Set the path to the project name under you CopSSH user’s home directory, select “Central repository, no working dir”(because we are the server),  then “Initialize”:
image

f. On the client side, open Git Extensions, click “Clone repository”:
image

g. On the client side, the repository address should be ssh://jinweijie@ryan-vm-01/ICW/home/jinweijie/mydotnetproject Please be aware that, the repository should begin with c:\ on the server.
image

h. On the client side, click “Load SSH Key” and load the key which was saved in step 4-b:
image

i. On the client side,  enter the password if you set password to the key, then click Clone:
image

j. On the client side, add ignore files:
image

k. On the client side, open Visual Studio, create a project to mydotnetproject folder(which is the cloned repository), you may find the files are already under git source control:
image

l. Click the “Commit” button on the menu bar, then click “Commit & Push”:
image

m. Push succeeded:
image

n. On the server side, you can find the new pushed files:
image

That’s all, happy GITTING!

(Ref: http://www.codeproject.com/Articles/655560/Step-by-Step-Setup-Git-Server-on-Windows-with-Co)

[.NetWorld] SharePoint Architecture – What are we talking about here?

As I have announced in my previous post – I will start a series of the architecture related SharePoint articles on this blog. This is merely caused by the lack of the proper architecture, in a huge number of the SharePoint applications I have seen. That, on another side, has been caused by numerous reasons, but nevertheless: we have somehow come to the point, where it has become acceptable that the front end talks directly to the back end. Say, a SharePoint web part communicating directly with the data in the SharePoint list.

Well, it is not acceptable, not in any other technology, and not in SharePoint.

As I have written before – this series of the articles will be accompanied by a CodePlex project, where all of the staff which I talk about in these articles, will be accompanied with the real, living code. The test solution will be the about the conference organization: if you have ever been to a SharePoint conference, or any other development conference for that matter, you know that there is a lot of stuff to be done – from the speakers’ perspective (speaker bios, session abstracts, session schedule…), but mostly from the visitors’ perspective (applying for the conference participation, registering for a single session, rating a session…).

Of course, we will want to have a nice, modern way of doing things – we want visitors to register to a session simply by scanning a QR code on the door. We want them to be able to rate a session in a nice web interface on the conference web page. Even better, with a Windows Phone 7 app. OK, maybe even with the mobile-optimized HTML5 page (there are still some folks out there which are not using Windows Phone, from whatever reason it might be).

Conference administrators, on the other side, will mainly use the standard SharePoint interface for managing the conference data – visitors, sessions, schedules etc. But we want to make their lives a bit easier – we want them to know the session ratings immediately after the visitors have given them. We want them to know the session visitors immediately after the session end. And we would like to give them a nice geographical distribution of visitors, overview for the whole conference, and for each single session.

This will be our project. As you can see, a lot of work is waiting there, but we have to start somehow.

It is obvious, even now at the beginning, that a solution without architecture would not give us any benefits here. Just consider the task of rating a single session. We have said – we want it to be possible to do that through the web interface. Let’s say – we need a web part for it. Then we have said that we want to make it possible through the WP7 app. And, on the end, we want a sleek app for the non-Windows Phone mobile devices. Should we then develop this logic three times? Once, we talk directly to the SharePoint from the web part. Then we develop the same thing for the Windows Phone. Then we develop a special page which would be optimized for the other mobile devices. Now, that does not make any sense, does it? We need to have one piece of code for rating the presentations. Our web part, our mobile devices optimized web page, our WP7 app – they need to talk to that piece of code. So when we change the rating logic, it’s changed everywhere.

Not to mention, how much easier testing of that code will be when we write it only once. And testing is also kind of important. As we see, it’s all about architecture.

So, how does a generic architecture for a complex SharePoint solution looks like? Well, there is no uniform answer for it. It all depends on the needs of the application. But the next picture can give an overview about some standard cornerstones which should be found in the solution.

APArchitecture - Simplified
We see quite a number of boxes here, even if it is a simplified model. It would be too much, to explain it all in one article, but, let’s just identify here architecture layers we have used in this example:

SharePoint UI Layer

This is all about SharePoint, so let’s start with the stuff which should be well known for most of the SharePoint developers – SharePoint UI Layer. Web parts, ASPX pages, workflows, event receivers…

Wait a moment. Workflows and event receivers are in the UI Layer?! Well, a kind of. Of course they are not really UI, but when you think about it – they actually do a typical UI tasks: they trigger business processes. Of course we can make them actually EXECUTE business processes, but we can do that in a web part as well, can’t we?

You get the idea -a web part, an ASPX page – it is all UI, they don’t do any business – they interact with user, they collect data, and they give that data to someone else to do the dirty work. If we think about our example solution – conference organization – this is where the visitors will give ratings to the sessions. They will see a form, they will enter ratings, and they will click the OK button. That’s it.

Business Layer

This is where the dirty work has been done: we actually need to DO something with the input data which comes here. And yes, we also define our data model here (data entities). If you think from the SharePoint perspective, you don’t want to write a series of strings and numbers (which represent our rating) in the fields of a SPListItem. Of course you can do that, but, then good luck with validation, testing, debugging, and, oh yes – with the maintaining that code. That is the reason why we will have the Rating entity, where we will store our ratings. We will have a number of supporting methods for that rating – to validate rating, to calculate the average rating (not as simple as you think!), well, a number of different things to do. You can’t do that with the values of the fields in the SPListItem object.

architecture layersAnd yes, this is theoretically the only layer of the solution which you will never want to replace. You might improve it, you might add some new functionality, but this is the ONLY part of the solution which you don’t want to replace. You can replace the front end – you can develop new web parts, you can develop new interfaces for new devices, but they will all talk to your business logic. You can also replace the back end – your customer might tell you that she has, after a long and painful thinking process, decided that she does not want SharePoint Server on the back end. She wants a SQL Server. You might curse, but you will make a new Data Access Layer, with new persistence methods. Your business logic stays the same. It didn’t change, did it?

Data Access Layer

And this is where you write your data to the SharePoint, and where you read it from there. You don’t do any calculations here (like calculation of the average rating), you simply read and write your data. It is more than enough work for this piece of code.

And you will want to have more than one Data Access Layer implementation in your solution. You will at least want to have a mock implementation, so you can make some isolated tests, without bothering about SharePoint. Or, from the example above, you might want to implement an alternative, SQL Server Data Access Layer. All this can happen. So, this is why you need an interface. Your interface is basically telling what the Data Access Layer has to do, and the different implementations of this interface (SharePoint, SQL, Mock…) will do that. Since this interface is closely related to our business entities, it is stored in the Business Layer, but all of the different Data Access Layer implementations will implement that interface. It might seem odd at first, but it is actually quite handy.

There is another challenge with the SharePoint implementation of the Data Access Layer. It needs to be aware of the context. Well, you might think, but we know the context from the front end – SharePoint UI elements? Yes, we do, but we have the Business Layer in between, and it has no idea about the SharePoint context. Why should it? It shouldn’t even know, where are we storing the data that it is manipulating. And, if you think about it, our WP7 and HTML clients will also not be aware of the context. These are the challenges we will deal with in the following articles.

Data layer

Data layer is pure SharePoint Server, SQL Server, or whatever we want it to be. In the case of SharePoint, we need to configure it, to create lists and libraries, create workflows, change different settings.

Infrastructure Layer

This is where we do our common stuff. Logging, application configuration, exception handling, dealing with localization (a huge issue in SharePoint) and similar stuff. Where are we going to log? ULS is the natural answer for the SharePoint, but what if we want to switch the logging to, say, Event Log, or to the local text file? Do we need to refactor our solution to change that stuff in all pieces of code where we have used the logging? Do we have different logging implementations in the front end and business layer (front end might not be SharePoint-aware)? And how do we configure that logging and the application in general?

All those questions will be dealt with in the infrastructure layer – I can already tell you that it will contain a number of interfaces, and a number of the implementations of those interfaces. And that a huge portion of this series of articles will be devoted to the infrastructure layer.

Service Layer

We need to expose our business logic to the outer world – we might have some quite different client implementations. Some people are still using iPhones. Scary, I know, but that’s the fact. And different clients can have different ways of communication. No problem, we can cover them all – WCF, REST, even the good ol’ ASMX is not quite dead yet (and it is aware of the SharePoint Context). This stuff will be our interface to the world.  Whatever might be out there.

UI Layer

This is all UI, which is not the SharePoint UI. And as we have said – it can be a lot of things. Silverlight application, different .NET managed clients, web stuff, interfaces to the other applications, whatever you might think of. Very often you will not even control it – there will be other people and applications who will want to connect to you. It’s all UI for you.

Wait, Silverlight? And managed .NET applications? Don’t we have the SCOM (SharePoint Client Object Model) now? Aren’t we reinventing a wheel with this? No, we are not reinventing a wheel. Or do you want to develop the session-rating logic again in your Silverlight client? And when rating logic changes, you need to change it in two different pieces of code? We don’t want that.

Is the CSOM obscure then? Useless? Not at all. CSOM is a great thing, if you have a LOB application which needs to exchange the data with SharePoint. Or, to use SharePoint’s collaboration features – document storage, collaboration, versioning… This is where the CSOM is your (very) good friend. When your business logic stays in the external LOB application, and when you just need a way to persist the data in the SharePoint, this is the playground for CSOM. But you shouldn’t implement the business logic with CSOM, from the numerous reasons, which were all stated above at least once.

But it is enough for now. In the next article, I will describe our Conference Organization solution, it’s parts, and finally start coding. Until then, cheers.

(Ref: http://blog.sharedove.com/adisjugo/index.php/2011/09/03/sharepoint-architecture-what-are-we-talking-about-here)

[Discovery] Tìm hiểu động cơ diesel

Trong một bài viết gần đây của GenK về động cơ ô tô, chúng ta đã cùng tìm hiểu cấu tạo và nguyên tắc hoạt động của động cơ đốt trong, loại động cơ được sử dụng trong các xe ô tô hiện nay. Chúng ta đã được biết những hệ thống hỗ trợ cho động cơ hoạt động ra sao, cũng như một số thuật ngữ và ký hiệu cơ bản khi nói về thông số của một chiếc động cơ.

Tìm hiểu động cơ diesel

Tuy nhiên trong bài viết trước chúng ta vẫn chỉ đề cập chủ yếu đến loại động cơ chạy xăng, thường dùng trong các loại xe sedan cỡ nhỏ. Còn những chiếc xe tải cỡ lớn hiện nay hầu như đều sử dụng động cơ dầu diesel. Vậy tại sao những chiếc xe cỡ lớn phải sử dụng động cơ diesel, sự khác biệt của nó với động cơ xăng là gì, cấu tạo và nguyên tắc hoạt động như thế nào? Chúng ta sẽ cùng tìm hiểu trong bài viết này.

Lịch sử phát triển

Rudolf Diesel – kỹ sư tốt nghiệp xuất sắc tại Đại học Kỹ thuật Munich của nước Đức đã sáng chế được một loại động cơ đốt trong và bằng sáng chế cấp cho ông vào năm 1892 bảo hộ quyền tác giả của động cơ mang tên diesel.

Động cơ diesel đầu tiên trên thế giới của Rudolf Diesel.

Động cơ diesel đầu tiên trên thế giới của Rudolf Diesel.

Cùng với sự phát triển của ngành công nghiệp xe hơi, động cơ diesel đã được cải tiến liên tục. Mặc dù vẫn còn những nghi ngại liên quan đến khả năng vận hành, độ tin cậy, mức tiêu thụ nhiên liệu…, nhưng một số công ty đã cố gắng ứng dụng động cơ diesel vào xe hơi.

Mercedes trở thành nhà sản xuất ô tô đầu tiên trên thế giới trang bị động cơ diesel cho chiếc 260D từ năm 1936. Quá trình thử nghiệm lô taxi 260D tại Đức đã thấy được hiệu quả và tuổi thọ thực sự của động cơ diesel nên động cơ diesel đã thu hút được sự quan tâm của người tiêu dùng thời bấy giờ.

Sự thành công của Mercedes đã khích lệ nhiều công ty tham gia sản xuất và lắp đặt động cơ diesel cho xe hơi, trong đó có Audi, Cadillac, Ford, Buick, Chevrolet, Volvo và BMW. Vai trò của động cơ diesel càng rõ nét hơn khi xảy ra hai cuộc khủng hoảng dầu lửa vào những năm 1970 và 1980.

Dù có nhiều ưu điểm vượt trội, nhất là tiết kiệm nhiên liệu hơn động cơ xăng khoảng 30% nhưng động cơ diesel vẫn ít phổ biến hơn động cơ xăng do những hạn chế cố hữu về tiếng ồn và khí thải.

Động cơ diesel và động cơ xăng

Về cấu tạo, động cơ diesel không có nhiều khác biệt so với động cơ xăng. Điểm khác nhau ở đây nằm ở hệ thống cung cấp nhiên liệu và diễn biến quá trình nạp – nén – nổ – xả.

Tìm hiểu động cơ diesel

Động cơ diesel là loại động cơ đốt trong tạo hỗn hợp cháy (nhiên liệu – không khí) ngay bên trong xilanh (giống động cơ GDI), hoạt động trên nguyên tắc tự cháy (tự kích nổ) trong điều kiện môi trường áp suất cao, tỷ số nén lớn (trong khoảng 14:1 đến 25:1) mà không dùng bugi để đốt cháy hỗn hợp không khí-nhiên liệu.

Loại nhiên liệu sử dụng cho động cơ diesel là dầu diesel nên chỉ tiêu nhiên liệu khác với xăng. Nhiên liệu diesel sử dụng chỉ số kích nổ là Cetan trong khi xăng lại là chỉ số Octan, như vậy diesel sử dụng nhiên liệu càng dễ kích nổ càng tốt giúp động cơ sẽ dễ khởi động hơn khi nhiệt độ môi trường xuống thấp.

Hệ thống cung cấp nhiên liệu

Hệ thống cung cấp nhiên liệu cho động cơ diesel bao gồm các thành phần chính: Thùng nhiên liệu, bơm nhiên liệu thấp áp, bầu lọc thô, bầu lọc tinh, bơm cao áp và kim phun. Bơm thấp áp có nhiệm vụ hút nhiên liệu từ thùng dầu qua các bầu lọc thô để cung cấp nhiên liệu cho bầu lọc tinh và bơm cao áp. Bơm có hai dạng là bơm màng hoặc bơm piston.

Tìm hiểu động cơ diesel

Bơm cao áp có nhiệm vụ cung cấp nhiên liệu cho từng vòi phun đúng định lượng, thứ tự nổ theo chế độ bàn đạp ga. Bơm có dạng piston được dẫn động nhờ trục cam để điều khiển theo thứ tự nổ, được điều khiển đúng định lượng nhờ thanh răng xoay rãnh của piston thông qua dẫn động tới bàn đạp ga và bộ điều khiển theo tải nhờ quả văng ly tâm.

Kim phun có nhiệm vụ tiếp nhận nhiên liệu từ bơm cao áp cung cấp và tán nhuyễn tạo thành sương, phun vào buồng đốt của động cơ với áp suất cao và nhờ hình dạng của đỉnh piston tạo thành vùng xoáy lốc để hòa trộn đều với không khí.

Quá trình nhiên liệu đốt cháy

Ở động cơ xăng, hỗn hợp cháy được đưa vào động cơ để thực hiện hành trình nén và được kích nổ nhờ bu-gi đánh lửa tạo quá trình cháy, dãn nở và sinh công. Do đặc điểm như vậy nên động cơ xăng có thêm hệ thống đánh lửa. Đối với động cơ diesel, sau khi kim phun nhiên liệu thực hiện phun với tốc độ và áp suất cao kết hợp với buồng xoáy lốc trên đỉnh piston tạo ra hỗn hợp cháy. Hỗn hợp này được nén với tỷ số nén cao và tự bốc cháy, dãn nở và sinh công.

Tìm hiểu động cơ diesel

Hiệu suất của động cơ diesel lớn hơn khoảng 1,5 lần so với động cơ xăng. Nhiên liệu diesel thường rẻ hơn xăng, 1 lít diesel khi cháy hoàn toàn nhận được khoảng 8.755 calo trong khi 1 lít xăng cháy hoàn toàn cho khoảng 8.140 calo. Suất tiêu hao nhiên liệu của động cơ diesel là 200-285g/kWh nhỏ hơn của động cơ xăng là 260-380g/kWh.

Các công nghệ hiện đại trang bị trong động cơ diesel

Nhờ những cải tiến mạnh mẽ trong công nghệ vật liệu, lọc hóa dầu, động cơ diesel đã có điều kiện khắc phục được những hạn chế của nó. Ngày nay, tiếng ồn của loại động cơ này đã giảm đáng kể và quá trình đốt cháy nhiên liệu tốt hơn, khí thải cũng giảm nhờ các bộ lọc xúc tác, thời gian khởi động nhanh hơn, tương đương với động cơ xăng.

Tìm hiểu động cơ diesel

Bước tiến vượt bậc, đóng vai trò quyết định giúp động cơ diesel ngày càng được phổ biến rộng rãi chính là công nghệ tăng áp (T – Turbocharge) và phun nhiên liệu trực tiếp (DI – Direct Injection). Nhờ hai công nghệ chủ lực này, gần đây công suất của động cơ diesel không hề thua kém động cơ xăng trong khi vẫn giữ được ưu thế về tiết kiệm nhiên liệu.

BlueTEC là công nghệ làm sạch khí thải của động cơ diesel, cho phép tạo ra những chiếc xe thải khí ít ô nhiễm nhất hiện nay. Nguyên lý là sử dụng chất xúc tác hoặc bộ chuyển đổi để khử các hợp chất độc hại như CO và HC có trong thành phần khí thải, đồng thời thu gom muội than ở dạng hạt trước khi thải khí ra ngoài môi trường. Được bổ sung các bộ phận đó, tất nhiên giá của xe Mercedes-Benz BlueTEC không thể rẻ.

Tương lai của động cơ diesel

Động cơ diesel với ưu điểm nổi trội là sức kéo lớn, đặc biệt là các chi tiết của động cơ có tuổi thọ và độ bền cao, nên động cơ diesel luôn được các nhà khoa học hướng tới để nghiên cứu nhằm khắc phục những hạn chế.

Tìm hiểu động cơ diesel

Trong tương lai, chúng ta sẽ không chỉ thấy những chiếc xe tải cỡ lớn được trang bị động cơ diesel mạnh mẽ mà thậm chí cả những chiếc xe hạng sang hay xe thể thao cũng sẽ có phiên bản động cơ diesel . Hiện nay Mercedes, BMW và Volkswagen là những hãng đi đầu trong ứng dụng công nghệ diesel trên các sản phẩm hạng sang. Mercedes có E320 CDI với mức tiêu hao nhiên liệu 8 lít cho 100 km trong thành phố và 6 lít trên đường trường. Còn các sản phẩm chạy diesel của BMW có kí hiệu “d” dưới mã tên như 318d, 325d, 525d thậm chí cả dòng xe sang cao cấp serie 7 như 730d.

[Dev tip] Browser extensions to display GitHub code in tree format

https://github.com/buunguyen/octotree

Browser extensions (Chrome, Firefox, Safari and Opera) to display GitHub code in tree format. Useful for developers who frequently read source in GitHub and do not want to download or checkout too many repositories. Features:

  • Easy-to-navigate code tree like IDEs
  • Fast browsing with pjax
  • Support private repositories (require personal access token)

[Dev tip] “An existing connection was forcibly closed by the remote host” error in WCF service

For a difference, a post that has nothing to do with SharePoint, but rather with WCF. In my team today, we had a really strange behavior of one of our web services. Everything was ok, except in one method, which was always on the client side throwing the following exception:

“An error occurred while receiving the HTTP response to http://ServiceHost/ServiceName.svc. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.”

Looking at the inner exceptions, two more levels could be noticed:

The underlying connection was closed: An unexpected error occurred on a receive.

and

An existing connection was forcibly closed by the remote host

Googling it didn’t happen too much – some answers were going into direction that complex objects can not be serialized (which is not true, by the way), and other answers were going into direction that the serialized message length was too large, and that the maxRequestLength should be increased in web.config, something like:

<httpRuntime maxRequestLength=”Xyz”…. />

But hey, we were in the test phase, and our serialized messages were really small, this could not be it…

…or wait, could it be?

I looked again on our objects that we are serializing, and saw something like

1
2
3
4
5
6
7
8
9
10
public class MyClass
{
    public int Id { get; set; }
    
    public string Name { get; set; }
    
    public MyClass Parent { get; set; }
    
    public List<MyClass> Children { get; set; }  
}

OK, that’s it. In an instance of the object, we hold the instance of the parent object, and list of instances of the children objects. And while that’s ok in .NET class, because we are dealing with the “pointers” to the parent and child objects, it looks much different when we serialize it. It serializes the object, then it’s parent object, then the children of the parent object (our starting object is among them), then again the parent… And it serializes infinitely. Until we hit the maximal message size, whatever it would be.

Now, once the problem was diagnosed, the solution was also more than simple – we just put the DataContract attribute on the object, and exclude the “Parent” object property from the contract. Instead, we created a ParentObjectId property, getter only, which only returns the parent’s id.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
[DataContract]
public class MyClass
{
    [DataMember]
    public int Id { get; set; }
    
    [DataMember]
    public string Name { get; set; }
    
    //Notice - no [DataMember] here...
    public MyClass Parent { get; set; }
    
    [DataMember]
    public int ParentId
    {
        get
        {
            return this.Parent.id;
        }
    }
    
    [DataMember]
    public List<MyClass> Children { get; set; }
}

And voila – in the .NET libraries, we can still use the beauty of parent and children collection objects, and when we serialize it, we use the parent ids. Works like a champ. Simple problem, simple solution, but it has caused some thinking on our side.

[Dev tip] Cannot consume WCF service. (413) Request Entity Too Large

<bindings>
 <basicHttpBinding>
 <binding maxBufferPoolSize="2147483647" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" messageEncoding="Text">
 <readerQuotas maxDepth="2000000" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
 </binding>
 </basicHttpBinding>
</bindings>

Check IIS uploadreadaheadsize and set to 204800

cscript adsutil.vbs set w3svc/1/uploadreadaheadsize 204800

and increase max buffer size at send and receive port binding Properties . Restart the IIS and Host instance .