I found this funny quote today in one of the Russian forums.
Here is my translation:
Hogwarts feels like a software project that is going for decades, like (insert your favorite product here). Old bugs, undocumented features that no one remembers why they been created or how to use them, incompatibilities and a lot of ancient ‘temporary’ solutions that hold all this horror together. Also, several engineers were on this project for many years, and refuse even to try to solve them explaining that that’s the way it has always been and call the whole situation the ‘school traditions’ …
Friday, December 2, 2016
Sunday, November 27, 2016
Ideas... do they really worth nothing?
Some say that an idea by itself is worth nothing. I sort of agree with this statement. We share ideas all the time, but most of them remain … just an idea.
But when a raw idea is transformed into a vision, supplied with the solid technical foundation, a lot of will-power and hard work, only then will this wild idea have a chance to become a reality.
Several years ago, Hamid shared his big idea with me. It was cool, but at that time I wasn't fully convinced on how to implement it in the best way. Even though he had a couple of prototypes, it wasn't clear what problem this technology was trying to solve. It was like trying to boil an ocean.
After spending some time brainstorming and prototyping, it occurred to me that this idea had no future in its current form. So, I dropped it, but not completely, since it sparked another set of ideas, mostly around the building blocks and technologies. Ideas that I implemented as open source projects on GitHub.
Hamid was much more persistent with his grand vision. A couple of years after our initial attempt, he approached me again and presented me with a refined vision.
In the data visualization area, there are several major problems that many companies are trying to solve:
These days people expect a polished, smooth and fast UX and it takes great talent to make it happen. We were lucky to convince Renato, another friend who is a great UI / UX engineer ,to join us and help to make our product not only work fast but to look amazing as well.Over time, we built both a great product and a great, diverse team of the highly energetic and highly motivated engineers. And this was not an easy task considering that that team is geographically dispersed over three continents, six countries and numerous time zones :).
So, you can imagine the pride and joy we felt seeing a major healthcare company presenting a solution built on a top of our product at an annual summit they hold for all their clients!
The solution that we built from ground up, starting from designing a very complex database schema, defining a middle tier, and presenting a fast, fluid web interface with a set of complex views, dashboards, forms, server-side activities and many more UI features. And now imagine that all this work has been done without a single line of code and in less than three months!
So, if you tell me that ideas are worth nothing, I would say that an idea will cost a lot of hard work, constant pressure and lack of sleep, but it's damn satisfying to see the results!
It is totally worth it.
- Performance - how to display complex dashboards quickly?
- Latency - how to present this data real-time?
- Integration - how to connect to the client's data with minimal configuration and coding?
- Rapid development - how to build solutions as fast as possible?
- Price - how to make all this affordable even by the small companies Well, the last point might not apply to the titans of this business – usually, they are after the big contracts, but this good news for the small fish like us.
Tuesday, December 23, 2014
PowerShellAsync - library to build async-enabled PowerShell CmdLets
I love PowerShell.
Yes, I know it is not as good as <insert your favorite shell here>, but on Windows it makes my life easier.
I've been using it for many years now, built my own scripts for easy stuff and CmdLets for more interesting scenarios.
Lately .NET - based coding starts moving into asynchronous territory with a great speed - most of the modern libraries introduced a Task-based asynchronous API. Using these APIs we can write much more efficient code. And with introduction of .NET 4.5 and async keyword in C#, there are no excuses NOT to write asynchronous code anymore.
Unless you work on a PowerShell Cmdlet.
In typical CmdLet you implement at least one method:
In typical CmdLet you implement at least one method:
For more advanced scenarios, focused on processing pipelined data you may also consider implementing these methods:
From inside these methods you can interact with PowerShell using a family of Write-* methods like Write-Host, Write-Warning, Write-Verbose, etc.
Also you can ask user to confirm operations using ShouldProcess and ShouldContinue methods.
The only problem is that you can use these methods only from the main thread!
PowerShell validates the stack of the method call and if it is not initiated from one of the 4 primary CmdLet methods, it will throw an exception.
It makes writing asynchronous code using modern libraries a difficult task.
There are many ways to solve this problem, but my goal was to make writing async PowerShell code as easy as a normal one, and have a way to upgrade an existing CmdLet with a minimum effort.
Introducing PowerShellAsync library
First of all, to build a new async-enabled CmdLet or upgrade an existing one, you need to install PowerShellAsync from nuget:
PM> Install-Package TTRider.PowerShellAsync.dll
(https://www.nuget.org/packages/TTRider.PowerShellAsync.dll/)
And if you curious about implementation, feel free to take a look at the source: https://github.com/ttrider/PowerShellAsync
So now, instead of implementing the original methods, you have to implements their async counterparts! And all of the Write-* methods will work as if they been called from a main thread!
So, if you want your CmdLet to execute T-SQL statement on multiple databases at the same time using modern async API, here is your naive PowerShell CmdLet:
For the complete example, please take a look at Github: https://github.com/ttrider/PowerShellAsync/tree/master/PowerShellAsyncExample
Happy Coding !
From inside these methods you can interact with PowerShell using a family of Write-* methods like Write-Host, Write-Warning, Write-Verbose, etc.
Also you can ask user to confirm operations using ShouldProcess and ShouldContinue methods.
The only problem is that you can use these methods only from the main thread!
PowerShell validates the stack of the method call and if it is not initiated from one of the 4 primary CmdLet methods, it will throw an exception.
It makes writing asynchronous code using modern libraries a difficult task.
There are many ways to solve this problem, but my goal was to make writing async PowerShell code as easy as a normal one, and have a way to upgrade an existing CmdLet with a minimum effort.
Introducing PowerShellAsync library
First of all, to build a new async-enabled CmdLet or upgrade an existing one, you need to install PowerShellAsync from nuget:
PM> Install-Package TTRider.PowerShellAsync.dll
(https://www.nuget.org/packages/TTRider.PowerShellAsync.dll/)
And if you curious about implementation, feel free to take a look at the source: https://github.com/ttrider/PowerShellAsync
So now, instead of implementing the original methods, you have to implements their async counterparts! And all of the Write-* methods will work as if they been called from a main thread!
So, if you want your CmdLet to execute T-SQL statement on multiple databases at the same time using modern async API, here is your naive PowerShell CmdLet:
For the complete example, please take a look at Github: https://github.com/ttrider/PowerShellAsync/tree/master/PowerShellAsyncExample
Happy Coding !
Wednesday, March 12, 2014
Classic Case
As developers, time to time we have to deal with text cases in our code.
To my surprise, I didn't find this same level of support in WFP/Silverlight. Granted, you can mark your <TextBox> with CharacterCasing="Upper" or "Lower". But no support for Title Case!!! . And no support for other controls, like TextBlock, etc. !
But we play with text cases not only for output. Traditionally some of us do case transformations for case-insensitive compassion, which is wrong on so many levels:
First of all, even if you have to use ToLower or ToUpper method, it is a good practice to pass CultureInfo as a parameter. Your server may use one culture, but web request may come with a different culture! By passing culture info into formatting and case transforming methods you ensure that your customers will see what they suppose to see:
Don't get me wrong, this code is still bad - it is just marginally better then before. First of all, what if arg is null? Or str is null? Sure, we can add those checks, but it will make code even less readable.
Fortunately, .NET provides us with nice alternative: System.String static methods like Equals, Compare, Format, Join, etc.
So our code can look like this:
Actually it even runs significantly faster!!! And it is smart enough to take care of special characters !!!:
But if you want to be 100% sure that you are producing the right result, don't rely on System.String.Equals function - use System.String.Compare instead. It takes Culture as a parameter and guaranteed to perform checks according to provided culture rules.
CultureInfo is a very interesting class, it provides you with all information necessary to display your information correctly in different cultures and languages.
Here is the hidden gem that I found that can be used to To Display Dynamic String In Title Case:
So, bottom line:
Not that we always have to do it, considering that some UI platforms, like HTML/CSS will do this for us:
To my surprise, I didn't find this same level of support in WFP/Silverlight. Granted, you can mark your <TextBox> with CharacterCasing="Upper" or "Lower". But no support for Title Case!!! . And no support for other controls, like TextBlock, etc. !
But we play with text cases not only for output. Traditionally some of us do case transformations for case-insensitive compassion, which is wrong on so many levels:
First of all, even if you have to use ToLower or ToUpper method, it is a good practice to pass CultureInfo as a parameter. Your server may use one culture, but web request may come with a different culture! By passing culture info into formatting and case transforming methods you ensure that your customers will see what they suppose to see:
Don't get me wrong, this code is still bad - it is just marginally better then before. First of all, what if arg is null? Or str is null? Sure, we can add those checks, but it will make code even less readable.
Fortunately, .NET provides us with nice alternative: System.String static methods like Equals, Compare, Format, Join, etc.
So our code can look like this:
Actually it even runs significantly faster!!! And it is smart enough to take care of special characters !!!:
But if you want to be 100% sure that you are producing the right result, don't rely on System.String.Equals function - use System.String.Compare instead. It takes Culture as a parameter and guaranteed to perform checks according to provided culture rules.
CultureInfo is a very interesting class, it provides you with all information necessary to display your information correctly in different cultures and languages.
Here is the hidden gem that I found that can be used to To Display Dynamic String In Title Case:
So, bottom line:
- Use static methods of the System.String with Culture information for string comparison.
- Use CultureInfo's methods to UpperCase, LowerCase and TitleCase conversions.
Happy Coding!
Shameless plug: if you have to deal with SQL Server performance investigations, try my free web-based tool: http://supratimas.com
Friday, February 7, 2014
All about Lazy
Software Engineers are lazy. It’s a fact. And it is a good thing.
Lazy engineer would not copy same code over and over, she’ll extract it as a method. Lazy engineer will use a standard .NET feature (tested!) instead of rolling out his own.
Of cause we talk about good engineers. Not so good and lazy engineer will copy code around, causing support nightmare.
BTW, Visual Studio allows you to find this type of code clones: just right-click on the code block and select “Find Matching Clones in Solution”.
Later on, TFS, SVN or GIT will help you to identify those who code like that.
But enough about lazy engineers, today we are going to focus on lazy property initializes.
Let’s take a look at the typical object, that exposes a public property of collection type initialized on-demand:
Lazy engineer would not copy same code over and over, she’ll extract it as a method. Lazy engineer will use a standard .NET feature (tested!) instead of rolling out his own.
Of cause we talk about good engineers. Not so good and lazy engineer will copy code around, causing support nightmare.BTW, Visual Studio allows you to find this type of code clones: just right-click on the code block and select “Find Matching Clones in Solution”.
Later on, TFS, SVN or GIT will help you to identify those who code like that.
But enough about lazy engineers, today we are going to focus on lazy property initializes.
Let’s take a look at the typical object, that exposes a public property of collection type initialized on-demand:
SomeStrings property would be initialized when it gets accessed for the first time. So far so good.
But imagine you have 5 or 10 properties like that on a class. It is a lot of typing… (remember – lazy!)
There is a way to slightly minimize typing by using ?? operator
The ?? operator is called the null-coalescing operator. It returns the left-hand operand if operand is not null; otherwise it returns the right hand operand. So our property code can be changed like that:
But what if we have to make this property accessor thread safe?
At this point, we have a choice: we can try to implement thread-safe property initialization yourself, like in this HorrobleObject.
I’m pretty sure I've done it right this time, but I wouldn't bet on it.
It is possible that I missed some subtle nuance and it is going to bite me later.
So please, don’t use this code.
Fortunately for us, lazy but smart engineers, .NET framework offers the solution:
Using this class we can rewrite our code like this:
Lazy object is ideal for a singleton pattern, if you really have to have one.
It allows you to focus on business logic of you class, and not to be sidetracked by low-level details of thread-safe initializers.
Stricktly speaking, Lazy can be used not only in thread-safe scenarious, but in a regular code as well. You can indicate None, as threading mode and in this case Lazy will run without multy-threading overhead.
So, if you need to implement on–demand property initialization in your class, especially in thread-safe fashion, I strongly suggest you to use Lazy<T>!
And if you want to know, what it does under cover, you can take a look at its ~400 lines of code implementation here: http://bit.ly/1gaWjOm
But imagine you have 5 or 10 properties like that on a class. It is a lot of typing… (remember – lazy!)
There is a way to slightly minimize typing by using ?? operator
The ?? operator is called the null-coalescing operator. It returns the left-hand operand if operand is not null; otherwise it returns the right hand operand. So our property code can be changed like that:
But what if we have to make this property accessor thread safe?At this point, we have a choice: we can try to implement thread-safe property initialization yourself, like in this HorrobleObject.
I’m pretty sure I've done it right this time, but I wouldn't bet on it.
It is possible that I missed some subtle nuance and it is going to bite me later.
So please, don’t use this code.
Fortunately for us, lazy but smart engineers, .NET framework offers the solution:
public class System.Lazy<T>
Using this class we can rewrite our code like this:
Lazy object is ideal for a singleton pattern, if you really have to have one.
It allows you to focus on business logic of you class, and not to be sidetracked by low-level details of thread-safe initializers.
Stricktly speaking, Lazy can be used not only in thread-safe scenarious, but in a regular code as well. You can indicate None, as threading mode and in this case Lazy will run without multy-threading overhead.
So, if you need to implement on–demand property initialization in your class, especially in thread-safe fashion, I strongly suggest you to use Lazy<T>!
And if you want to know, what it does under cover, you can take a look at its ~400 lines of code implementation here: http://bit.ly/1gaWjOm
Thursday, January 30, 2014
Introduction of the series
Writing code is an exciting business. At least it always been like that to me. It is fast and ever-changing business.
Every day talented people strive toward making software faster, more stable, more secure. And at the same time, even more talented people are looking for ways to break it :-)
Hardware manufactures come up with new components that open up possibilities that were unimaginable just a several years ago. And at the same time these advances make certain ‘industry standard’ patterns and practices dangerous and obsolete.
But sometime later, when new developer decided to use modern initialization pattern and made a small change to the code, just replaced IDictionary with var: then BOOM, code no longer works:
The reason code used to work before and not anymore is that implementation of the Dictionary class is backward compatible, when casted into IDictionary interface, but when it is used directly, this class produced an exception, as it supposed to do.
But let's say that you are not aware of this change, and you keep writing code that relies on dictionary to return null, when key is not found. Yes, of cause if you have a solid set of unit tests to cover every line of your code and every possible combination, then you’ll see this problem right away. But we all know that unfortunately it is not a reality and code like that can sneak into production.
So the new, modern code should probably look like this:
As I said, this example is trivial, but nevertheless important to remember.
Every day talented people strive toward making software faster, more stable, more secure. And at the same time, even more talented people are looking for ways to break it :-)
Hardware manufactures come up with new components that open up possibilities that were unimaginable just a several years ago. And at the same time these advances make certain ‘industry standard’ patterns and practices dangerous and obsolete.
Keeping up with technology is very important for any kind of engineer, but for The Software Engineer it is an absolute necessity.
Every one of us have a favorite way of doing things and but time to time we have to re-evaluate our coding habits.
In this (hopefully) weekly blog I’m going to illustrate patterns, practices, code snippets that I find interesting, dangerous, cool, exciting ,etc.
Just to illustrate my point, I’m going to give you a simple example. I’m pretty sure that every one of you already knows about this coding pattern and never ever write code like that. You don’t, don’t you? ;-)
So, 11 years ago, in .NET 1.1, this snippet was perfectly fine:
but later, someone decided to upgrade to .NET 2.0 and use modern Dictionary object in initialization.
This code still works, as expected:Every one of us have a favorite way of doing things and but time to time we have to re-evaluate our coding habits.
In this (hopefully) weekly blog I’m going to illustrate patterns, practices, code snippets that I find interesting, dangerous, cool, exciting ,etc.
Just to illustrate my point, I’m going to give you a simple example. I’m pretty sure that every one of you already knows about this coding pattern and never ever write code like that. You don’t, don’t you? ;-)
So, 11 years ago, in .NET 1.1, this snippet was perfectly fine:
But sometime later, when new developer decided to use modern initialization pattern and made a small change to the code, just replaced IDictionary with var: then BOOM, code no longer works:
The reason code used to work before and not anymore is that implementation of the Dictionary class is backward compatible, when casted into IDictionary interface, but when it is used directly, this class produced an exception, as it supposed to do.
But let's say that you are not aware of this change, and you keep writing code that relies on dictionary to return null, when key is not found. Yes, of cause if you have a solid set of unit tests to cover every line of your code and every possible combination, then you’ll see this problem right away. But we all know that unfortunately it is not a reality and code like that can sneak into production.
So the new, modern code should probably look like this:
As I said, this example is trivial, but nevertheless important to remember.
Subscribe to:
Posts (Atom)