I am currently working on an ASP.NET Core project, which also contains angular2 on the front end. As much as I like Visual Studio as a C# IDE (especially with Resharper), there are much better solutions for writing frontend code. I personally am using WebStorm. I think it’s amazing, especially with support from Angular2. To have a nice build package, I am using gulp to compile all the code and copy to wwwroot directory. I keep all the files frontend related (ts, scss, html, images etc.) in separate directory - gulp is processing everything and saves results to wwwroot. The problem is, by default Visual Studio will try to compile your typescript files and place result JS in the same directory it have found the ts file. Today I just wanted to quickly share a tip how to disable that feature.
Some time ago, I was faced with a problem. I had to import a lot of data from a third party API. It sounds simple and it was, but the API was using a completely flat structure for the data. It was also using a naming convention, which was completely different from the one in my code. To top it up, names it was using were not consistent at all. I didn’t want to bring such a mess into my code, so I had to figure out a way to deal with it and transform this data into something nicer. The code I will be showing here was written in c#, but I am sure you can apply this pattern in any platform you are using. The API was providing me with the information on a certain product. It was used to display a configurator of this product on a website, so I was also getting data about possible values and if some properties should be hidden from the user. Everything was coming as a list of properties looking similar to this class:
For those of you who don’t know, MiSeCo is a little project I started for a blogging challenge back in March. It’s an idea that came to me when I had to deal with WCF services. It struck me how not dev-friendly this technology is and I thought I would be cool to come up with something nicer. I wanted to create a .NET Core framework you would add to your class library as a nuget package and it would transform it to a microservice able to communicate with other services using this framework. And it would all happen without or with minimal configuration needed. You can read more about it in the MiSeCo category.
Last week, I have recommended a tool for analyzing .NET projects called NDepend. Today, I would like to present another, amazing piece of software called NCrunch. It’s a plugin for Visual Studio, which, compiles your code in the background and runs all tests found in the solution. Of course you can tell it which projects it should monitor or which tests it should run, but the idea is that whenever you modify a single line of code, NCrunch knows what it has to compile, which test is covering this line and it immediately executes tests affected by your modification. And it’s fast. Incredibly fast.
Intro - svn, git…. Tfs
I have roughly 10+ years experience of working with version control systems. I started with SVN and a few years ago made a total transition to git. It was refreshing, how easy and fast was git compared to the SVN. Easy branches, merges… Everything was (and is) great. Now, since few months ago, I am working on a project, which is hosted in TFS. For the past few years, I’ve seen many comments regarding the version control from Microsoft. They were not positive (TfuFS ;)). When I learned that the project I will be working on is using TFS, I was a bit worried. Then, at first, I thought it’s not that bad. It wasn’t git (I still use it locally to track my changes in this project), but I could have lived with it. Now, after few months I think I learned enough to be able to confirm all these comments I read before - do not use TFS if you can avoid it.