Sublime is sublime Closing

Well its an early morning. I can blame the travel from London for that. I managed to struggle through to the end of the second period watching the canadiens game last night. I was a bit worried entering the third but was quite happy to see they won when I woke up :)

In this post I just want to sum up the other posts from the sublime series as well as add a few tidbits. In the post series we have learned how to setup sublime for .net development. We have covered how to setup project/solution support. How to get intellisense and some basic refactoring. Even how to get automated builds and tests running (all in linux).

We have also looked at a lot of other things that are built on top of sublime that are fairly useful if you are doing other types of development such as javascript or html5. Many of these tools far outclass the Visual Studio equivalents and are usable with many other environments (such as using a ruby backend).

I have personally given up on using Visual Studio as a whole. I will however keep a vm with it on it for some very specific tasks that it does well (such as line by line debugging). These are not things I use in my daily worksflow but are nice to have when you absolutely need them.

Some other changes have come about in the use of sublime as my primary editor. A big one is that when I am writing one off code (which I do alot) I do not bother creating project or solution files any more. I instead just create C# files then either run the command line directly to the compiler or create a small make file. It sounds odd but its actually much simpler than creating project/solution files overall.

There will also be much going on in this space coming up. As of now the sublime plugin supports maybe 20% of what omnisharp is capable of. There will be quite a bit of further support coming in. As an example I was looking the other day at supporting run tests in context from inside of sublime (in test->run test, on fixture->run fixture). There is also much coming in for refactoring support and my guess is that you will see even more coming in on this due to nrefactory moving to roslyn. I think within a year you will find most of this tooling built in.

Another thing that I added to sublime though there isn’t really an official plugin for it yet is sublime repl + script cs. I find it quite common to grab a function and work it out in the repl first and then move it back into the code. A perfect example of this happened to me while in London. I was trying to combine to Uris and was getting some odd behaviour. Three minutes in the repl showed exactly what the issue was.

Moving to sublime will change the way that you work a bit but is definitely worth trying. Remember that a primary benefit of working in this way is that everything that you are doing is a composition of pieces that will also apply to any other code you happen to be working on (whether its C/Ruby/Erlang/even F#).

Posted in Uncategorized | Leave a comment

.NET Developer Tooling: The Roslyn Revolution

Unless you’ve been on holidays for the last week on an island without internet,  you’ve probably heard that Microsoft announced that Roslyn is now available as Open-Source.

Roslyn is the next C# and VB.NET compiler, developed with these languages. It is not just a compiler but also provides an extensive set of APIs to do plenty of interesting stuff on source code including, intellisense, refactoring, static analysis, semantic analysis… This paradigm is called Compiler as a service.

Until now (I mean until Roslyn will be integrated in VisualStudio) the offer proposed by Visual Studio concerning these areas was pretty limited. If you need more than basics (in other word if you are a seasoned pro .NET Developer that value its time) you are certainly using daily Jetbrains Resharper or DevExpress CodeRush. But with Roslyn finally becoming a reality, these two well established tools teams are facing a dilemma. To use Roslyn or to not use it??!

A risky decision must be taken

  • Don’t use Roslyn, and take the risk that the Roslyn revolution will challenge the leading position. Another risk, more subtle but it’ll be very noticeable, is that Visual Studio will host in-memory the Roslyn infrastructure. So not using Roslyn will result in asking users to host two compiler/analysis infrastructures in its VS process. This will have a crucial consequence on both memory-consumption and performance. Not using Roslyn is the choice of the R# team and I am worried a bit since I am a big fan of R#.
  • Do use Roslyn, and take the risk to spend a massive refactoring effort for at least one release cycle, effort that could be spent on new features to increase competitiveness. Also, while Roslyn have been developed by some of the smartest brains on earth, it might not be suitable for doing everything. R# developers are claiming that their solution-wide analysis is not really doable with Roslyn. But investing into such huge refactoring is the choice of the CodeRush team. One important advantage with relying on Roslyn is that CodeRush will have future language features almost for free. This can pay off over the long term.

While my preference goes today to R#, it is likely that in five years from now, there will be one leading tooling built upon Roslyn, to achieve all these goodies (refactoring, analysis…). Will it be:

  • A VisualStudio extension developed by Microsoft. I have no idea if such project exist but it’d make sense. At least a partial product must be actually developed I guess.  A partial product that is not trying to implement all what CodeRush or R# can do, but at least increase substantially the actual basics  provided by VS out-of-the-box today.
  • CodeRush
  • A VisualStudio extension developed by a third company, we haven’t heard about yet.

Also we must take account that CodeRush and R# are actually super-mature products. Both teams are taking high risks for the future and it is not clear that another product (developed by the VS team or another team) might one day achieve such level of maturity.

Concerning NDepend

NDepend has never been meant to compete with CodeRush nor R#. Some few features overlap, but many NDepend users are also using CodeRush or R# (like me actually).

NDepend is super-optimized to do macro-analysis. It does check hundreds of solution-wide code rules per second, while CodeRush and R# can do solution-wide checks, but more like in a matter of minutes on real-world large code base.

CodeRush and R# are brilliant to achieve micro-analysis, like showing to the user within the code editor that something can be improved in a method body. NDepend touches some of these areas, but a tool like CodeRush or  R# prove to be invaluable to obtain smart advises in all situations. And they come with the wonder of refactoring.

NDepend offers the necessary ten-thousands foot perspective, in order to take the most relevant refactoring decisions, like about what to do to make a component more cohesive, more re-usable, less coupled, less spaghetti-like. CodeRush and R# are excellent to actually achieve the refactoring once a decision has been taken.

Also, NDepend lets write custom code rules through LINQ queries. I believe our API, for that matter, is close to optimal. For ruling that Base class should not use derivatives it is as easy as writing:

No need to create a VS project. No need to click a compile or run button. Result is well formatted, well browsable and live updated if the rule gets edited. Such rule is executed in a few milli-seconds, even against a very large code base. And could the syntax be more concise? (thanks LINQ, thanks fluent API).

In addition NDepend has many other useful features out-of-the-box including code visualization (matrix, graph, treemap), code diff/baseline, code trending, reporting, code metrics including code coverage, tons of smaller-scale facilities to perform all sorts of convenient action… and many others features are in the development pipe. None of them really overlap with what other tools offer.

I went through all this description to say: NDepend is living in its own niche-area. So far it cohabits gently with CodeRush and Resharper and it doesn’t consume much extra memory nor extra performance. My opinion is that NDepend will cohabit well with Roslyn, without the need to be rebuilt upon it. If you don’t really agree with this, we’d be glad to hear your stance.

Posted in CodeRush, Compiler Service, LINQ, NDepend, Resharper, Roslyn | Leave a comment

Extending Splunk’s search language with custom search commands.

I recently blogged on a feature which I worked on, custom search commands for Splunk in our Python SDK. Custom search commands allow you to extend Splunk’s search language with new commands that can do things like apply custom filtering, perform complex mathematical calculations not in the box, or generate events dynamically from an external data source like an external API. Currently we only support them in Python but we’ll be adding more languages in the future.

In the first post of the series I talk about how to build a simple generating command.

Screen-Shot-2014-04-14-at-3.52.49-PM

http://blogs.splunk.com/2014/04/14/building-custom-search-commands-in-python-part-i-a-simple-generating-command/

Posted in splunkdev | Leave a comment

Oh XAML, how I hate your error messages

I like XAML, I like some of the cool things I can do with it (although I do wish it was more like CSS in some ways). However, for something that has been around since 2006 why do your error message suck so bad and provide so little information.

Recently while making a very benign change to one of my resource files I received the following error when I launched my Windows Phone 8 application in the emulator.AccessViolationError

Of course I was stumped by this, in fact in my 4+ years of working with XAML I can honestly say that I never remember seeing this error. To try to resolve the issue I did what any good developer would do, stop the app and try again… It still happened.

Next, I thought maybe the emulator vm was screwed up so I killed the emulator and restarted… It still happened.

Ok, I knew it had to be something I did so I started diff’ing all the files I have changed to see if I could find what is causing this, fortunately for me I had only changed a few files and most were resource files. Immediately I noticed the issue, I had fat fingered something in my resource file, see below.
BadXaml

Notice how at the end of my line I had added an inadvertent slash at the end, yea this was my issue. So it turns out that invalid markup will give you the error mentioned above… WTF, really? Why is this not some sort of parse error?

I would totally have expected to get a parse error with the EXACT line number the error occurred, not some obscure error about memory. #Fail

Oh well, I should have known better I guess.

Till next time,

Posted in Windows Phone | Tagged | Leave a comment

How does TypeScript help prevent bugs in JavaScript

JavaScript is an awesome language once you grasp its power and its features. However, like all dynamic languages simple and stupid bugs can creep their way into your code if you are not careful. Many times this happens because types change over type but since JavaScript is dynamic it is really, really hard to detect these changes in an enterprise scale application.

TypeScript helps to solve this problem by providing compile time Type checking. This compile time checking can be used to generate type symbols on your code and alert you, via build errors, when you introduce a simple bug.

Take this code below for example of what I mean
Typescript.Original

Do you see the error? Look carefully, it is there?

Give up? Image blow has it pointed out
Typescript.Underlined

Since I am using KnockoutJs here and trying to set a value on an observable I cannot set the value this way.  I need to set it via method notation.

If we were to add typing to our code as below we would immediately be notified there was an error rather than at run time.

Typescript.Squiggle

Notice how once I added the typing information to the code the TypeScript compiler was able to tell you that you have a issue in your code, red squigglies and all.

Once we fix our code, as seen below, we are golden.

Typescript.Fixed

Now I am not making the claim that TypeScript will fix everything. What I am saying is that by introducing typing into the code and allowing that typing information to flow through your code you will potential to create cleaner and more stable code.

Till next time,

Posted in TypeScript | Leave a comment