[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.

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

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.

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

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

b. Just use the default account as CopSSH provides:

c. After installation, open COPSSH Control Panel

d. Click Add button in Users tab

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

f. Allow all the access:

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

h. Click Add:

i. Use default key settings:

j. Enter the Passphrase and File name:

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

[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

[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:
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.

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

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:

4. Configure private key on client

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

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):

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

5. Create repository, integrate with Visual Studio

a. Install gitextensions on both server and client.

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.

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

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

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”:

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

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.

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

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

j. On the client side, add ignore files:

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:

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

m. Push succeeded:

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

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.