Stack Overflow profile for Roopesh Shenoy

Startup Material

Published on May 5, 2012

Someone asked on a mailing list how do you find out who’s “startup material”.  Here’s my take -

  • Stupid enough to start a company
  • Naive enough to trust others (partners, customers, employees)
  • Dumb enough to work hard for lesser pay, when you could be earning more with less work
  • Insanely patient through n-number of failures
  • Extremely optimistic under any circumstances
  • A stress junkie
  • Ability to involve other “startup material” folks in your idiotic plan
  • All in hopes of a rich pay day and an opportunity to “do something” (yeah right, as if that’s important) even if the statistical probability of it actually happening is 0.01% (note the point about extreme optimism above)

So, are you “startup material”?

Filed in Uncategorized | No replies

The Myth Of Working Long Hours

Published on April 11, 2012

I recently came across a Job Description on a Start-up Forum, looking for Software developers for a fast-growing company. Things looked interesting till I reached a line which listed this as one of the requirements – “Ability to work long hours”

Now before I begin, answer my question – how many hours do you work in a week on average?

Options are – a) < 40, b) 40-60 c) >60

working-hard

If you answered a) – congratulations, you guys are already doing great in terms of work-life balance and are probably going to agree with everything that follows in this article.

If you answered c) – I am sorry, but some of the following content might come across as harsh – you guys are spoiling work-culture everywhere and spreading the myth that more hours = more work. If you dig deep you might find something here that will convince you why this is not sustainable or productive.

If you answered b) – you guys are on the border and can be tipped easily on either side – please read further and try not to go over to the dark side.

Now my problem with Long hours –

  • Unless you are working for yourself, you are paid to work for a certain number of hours (which is contractually binding). Anything more and your employer is getting a free ride (unless there is a paid over-time pay, which is normally more per-hour than the regular pay)
  • In either case, 40 hrs per week is more than sufficient to do a ton of work – that’s 8 hrs per day (for 5 days a week), translates to 480 minutes – if you do your work without distraction, this is generally enough to meet expectations set and maybe even surpass it.

If you are working for 8 hrs per day diligently and still not able to meet expectations, then at least one of the following is true -

    1. Your employer is setting unrealistic expectations – they are paying you for your current skill level and productivity – ask them to set expectations accordingly
    2. There is a major difference between your employee’s expectation of your skill/productivity and the actuals – either set the expectation right (“I am a .NET developer, but no I am not a JavaScript Guru”) or find another job – don’t let your ego get in-between here and say I can make this work, in the long-term it will kill you. If you need a transition period to get upto the skill level that your employer has set, make that clear up-front – most often than not, this will not really affect your compensation, but even if it does, it’s usually worth it.
    3. Your employer makes you spend a lot of time doing things that are not really important – symptoms are, you work till late night preparing for a demo, next day the demo gets cancelled. Or you work on the weekend trying to fix a bug, but once you’ve fixed it, the customer is unavailable to actually deploy it. Time to find another job.
    4. You unknowingly spend a lot of time doing things that are not productive – which affects your actual work

For most, 4 is the biggest problem though they don’t know it yet – ever switched to the news site when you start a build and realized only an hour later that you are completely distracted? Or spent a lot of time replying to email helping people over and over again? Or do you feel like you always end up cleaning after others? If you are doing any of this, chances are that you are doing something you aren’t paid to do.

There is an excellent talk on personal productivity from Scott Hanselmann which highlights these problems and shows you how to focus on what needs to be done, rather than what keeps popping into your inbox – go watch it.

No, seriously, go watch it and then come back. I’ll be waiting here

PatientlyWaiting

Now I’m assuming you’ve watched the video by now, but if you haven’t please do. It will probably be the most important thing that you watch in your career – because it will define how you work, no matter what you work on.

“So all this applies to an individual; as a company looking to hire people, why should I care?”

  1. Hire productive people, not people willing to work long hours. Build a culture of productivity.
  2. Encourage your employees, however hard-working they are, to try and maximize their productivity, not the number of hours they spend in office. Long Hours are not sustainable – not only is productivity sustainable, it just keeps improving over time.

“Okay, but what if I hire productive people and then ask them to work long hours? Won’t that be doubly productive?”

No – you are just setting them up for burn-out that way. Not only that, longer hours give the false impression that we have more time to get the same stuff done, makes people tired, increases mistakes and actually reduces productivity – once your productivity reduces it’s really an uphill task to get it back. So what do you do? You work still longer hours. It’s almost a downward spiral from there.

“No but seriously – why can’t we work productively for 60 hrs instead of 40?”

Why are you so fixated on number of hours? That’s like thinking how fast I want to run ahead, without thinking which direction I want to go. If you are sure of the direction, you would much rather walk – especially if your destination is far off. Walk at a steady pace and reach your goal posts with lots of energy to spare. Building a company takes years, don’t try to short-cut that.

Besides life is about more than just work – let your employees spend some time with their family, work on their hobbies, even work on pet-projects and build their skills. Some of these will come back and reward you as a company many times over – happier employees are more productive and more loyal.

Invest in productivity instead of counting number of hours. Please.

Filed in Productivity | 4 replies

BDD Your T-SQL With TST

Published on March 20, 2012

Recently I started working on a project that used a lot of stored procedures for business logic. The SPs were written by DB rockers, but they were quickly becoming long, unwieldy and difficult to maintain. None-the-less, we had several requirements to be implemented that required either modifying these Stored procs, or even writing new ones (to fit into the existing reporting infrastructure).

In the search of ways to make this less painful, I came across T.S.T. – a unit testing framework for T-SQL. This provides a powerful assertion framework for T-SQL stored procs and functions, and provides other features such as grouping tests into suites and ability to setup and teardown. The tests are also automatically rolled back after recording their results, which means that your test data does not change the state of the database.

A few moments after playing with this, and I decided to do a test-run on production code. So far things look good. I am going to refer you to the site itself for more details of this framework, but these are some of my learnings -

  1. Stored Procedures are harder to test than OO code – there is no mocking/stubbing of stored procedure calls to reduce dependencies. Most of your tests start looking like integration tests.
  2. BDD works well with SPs especially if they house business or reporting logic. Writing Given-When-Then statements really helps when planning the tests
  3. Keep the tests manageable by breaking them into test steps (if you have done BDD you will this will come naturally to you). For each statement in the “Given.. When.. Then..” create a helper proc that does the actual work of either creating the test data or running the asserts (the actual call corresponding to the “when” can still remain in the test since that is generally a one line call).
  4. Reuse these test steps as much as possible, similar to how you would reuse Gherkin statements in BDD
  5. Keep a separate schema for your test procs or keep them in a separate database. Do not mix production code and testing code
  6. Try to keep your tests focussed on a single aspect.

 

Testing the Stored procs is hard, but the payoff is good. You can start modifying existing code base with a lot more confidence rather than having to rewrite everything in the application layer (and in the process losing some performance advantages as well). Well written SPs can be tested easily, and difficulty in testing an SP can signal that there may be some refactoring needed. Never-the-less, it should never be impossible to write good tests to cover your database code.

Filed in .NET,SQL,Uncategorized | No replies

Tags: , , ,

BDD With C#, F#

Published on February 27, 2012

This will probably interest .NET folks more than others – I have created a couple of github projects (here are the links for C# and F#) and uploaded the code – (you will have to install Specflow and F# for the samples to check these out, or you can just browse it at github)

  1. BDD using C#, with SpecFlow – there are still some Unit tests, but BDD provides the overall acceptance tests. ATDD (Acceptance Test Driven Dev) is really a step forward from TDD. If you open and read the BDD scenarios (*.feature files), you will see that they also double up as a spec for the library, and can be easily reviewed by BAs/Customers directly
  2. The same sample ported to F# – the functionality can probably be much better written in F# However, even with just porting same logic, the amount of code written is almost one-third that of corresponding C# code. (Same C# test harness is used in both the projects). I am still new to F# so with some experience we could probably write much more efficient code than this (in which case the difference will be still higher!)

For those who don’t have time to go through the samples, this following line demonstrates the power of functional programming –

let daysInBetween = [this.Year.AD + 1 .. secondDate.Year.AD - 1] |> List.map(fun p -> (new Year(p)).DaysCount) |> List.sum

(means: for all years between this dates’ year and second date’s year -> for each of them create a new year object and get days count  -> sum it all up)

As the tests show, the types can be easily consumed from another C# layer as classes (say for eg, an ASP.NET MVC website, which currently does not support F#). Also, contrary to popular belief, OOP is a subset of a functional programming, since you can still define types (similar to classes) but you can also have functions without having a class to house it. And Besides just being pretty, functional languages also improve concurrent programming and hence let your code derive maximum benefit from multi-core processors.

You can also mix and match – for instance it is just as easy to write the BDD test expressions in F# for testing C# code instead of vice versa.

Hopefully these samples will encourage more people try out F# especially where a lot of list based computation is involved, as well as try BDD wherever possible in your next project!

Filed in .NET,Uncategorized | No replies

Tags: , , ,

Silverlight – RIA Services with Code First And Gotchas

Published on February 6, 2012

I recently worked on building a Silverlight LOB application and that became the perfect opportunity to try out RIA Services along with Code First.

What does RIA Services do? Well, if you have built a Silverlight application, you will know that you have to write server side code and client side code separately – and that the server side exposes certain web services, which will be consumed by code written on the client side. A common pattern used is MVVM, where the server side logic uses Models, whereas the client side uses ViewModel(s) to wrap the service calls and provide a data context for binding to the Views. Views (as name suggests) takes care of the UI screens.

What RIA services does is it simplifies this by replicating all your server side models on the client side by generating code on the client (this code is generated everytime the silverlight project builds). Since the generated clientside view models have one-one mapping with the server side models, it also wraps the service calls necessary for CRUD operations, and has the appropriate notifications for updating the views. RIA Services takes care of the serialization and the deserialization of model data, so you code only against strongly typed classes. You can use the view-models directly in your views, as well as instantiate domain service calls to fetch data from the server. The server has a service context which exposes all the appropriate CRUD methods for each entity, including any validation or filtering logic if necessary (this is fully controlled by the developer).

This does deliver on its promise of building a Rich client CRUD applications painlessly, but it certainly has it’s own gotchas. Knowing them beforehand will certainly help.

  1. The current version is dependent on an older version of Entity Framework (4.1 vs the current 4.2). This will probably continue, considering that RIA services team works somewhat independently of the EF team. The worst thing about this, is that if you use Nuget and install EntityFramework package first, and then try to install RIAServices.EntityFramework, it will give you an exception (since it tries to install EF 4.1 whereas you already have a newer version). The solution is to not install EF, just install RIA services and Nuget will get the appropriate version of EF for you.
  2. Entity Serialization rules will take a bit of pain to understand and get it right. There will be several cases where the data is fetched on the server side by EF, but not serialized and received on the client side and you’ll be left wondering why. Here are some of the rules you have to follow (there are some good reasons for why it works this way) -
    1. Collections too need an [Include] attribute to be serialized and sent to the client. Along with this, for EF itself you need to remember to use the Include() LINQ expression to ensure that the data is fetched on the server side even before serialization. (you need LINQ expression to fetch data from the DB, the notation to tell RiaServices to serialize the collection property.)
    2. You explicitly need to mention the FKeys for reference properties. For eg, if you have a property of Customer type named Cust, then you also need an id property named CustID. Although you don’t have to worry about filling this manually, you can just use the reference properties and the dbcontext will take care of updating the id.
    3. Methods don’t get copied from server side to client side code. If you want certain code to be shared, you should put those files in the “shared” folder, either the entire class or at least as partial classes (the parts that you need on client side)
    4. You can define partial classes on the client side to extend the capabilities of view models generated by RIA services
    5. Attributes, attributes, attributes – you can use attributes for defining display order/other display properties, validations, control serialization, etc. on your serverside models. This does seem like polluting the model code, but it is much more efficient than writing this logic separately. For new-comers though, it may make things difficult to understand (they will just keep searching where the textboxes in a dataform are coming from, without realizing they have to look at the server model attributes).
    6. Calculated properties defined on the server side will just go as normal properties on the client side – for instance if you have film.Height and film.Width, and film.Area is a calculated property with only a getter, still on the client side a property Area is created with normal getter/setter. What happens is the Area property is fetched from the server and sent over to the client instead of being generated on the client side. So if you update height on the client side, it won’t immediately affect Area on the server side. Also since Area has a setter, you can by mistake set the area to a new value, but this will throw an exception on submit changes since your server model does not have a setter. Possible solutions are either put calculated properties in shared code, or if you don’t want to use this on the client side just use the [Exclude] property.
  3. The code gets generated every time you build the client project, not when you build the server project. This can be irritating if you are looking for some properties in intellisense that you just added on the server side but are not yet available (because you din’t build the client side after making your changes).
  4. You are going to write a decent amount of code-behind. This is because dealing with logic in the view model is painful, since you have a one-to-one mapping between your view models and models (unlike well designed MVVM code).
  5. IQueryable and IEnumerable are both allowed as return types for the server Get[Entity] methods. IQueryable works a bit like magic and is more preferable – you can put filters directly on the server side based on entity properties (even though you haven’t defined any parameters for the server side method) and this will fetch only the required data. This is very useful to avoid having to write too many server side methods or keeping unnecessary nullable parameters
  6. Comboboxes are a pain to deal with – you cannot use domaindatasource to bind to a combobox. Luckily comboboxextensions package should help.
  7. If you fill the reference property of an entity with another entity and send it back from the client to the server for an update it can give you problems – for instance the server dbcontext will think that the referenced entity is a new entity and will try to insert that into the database, whereas being an existing entity the id will already be present. This will cause an exception. Solution – on the server side, just set all the reference entities to null and let the corresponding fk IDs to handle the updates.
  8. If  you have any models that are not related to any database tables (for instance say report model) then good luck getting them on the clientside! Entities not mapped to the database are not considered by Ria services. This is really wierd, and I ended up with empty tables just to get the corresponding viewmodels generated. This wierdness extends to reference properties as well – if for some reason you don’t want them to be mapped to the database, then they won’t be copied to the client code.
As long as you keep the gotchas in mind, working with RIA services is a decently productive experience.

Let me know how your experience has been so far. Did you find any more gotchas?

Filed in .NET,Silverlight | No replies

Tags: , , ,

Shallow Copy Object Properties between different types

Published on January 27, 2012

Have you ever repeatedly written assignment code, which just copies same named properties from object of one type to object of another? Here is a simple extension method that can be used to shallow copy a non-collection type object. This copies the values from a source type to a destination type, by matching property names.

public static void CopyTo(this Object source,
                          Object destination,
                          string excludeProperties)
{
      Type SourceType = source.GetType();
      Type DestinationType = destination.GetType();
      string[] excluded = null;

      if (!String.IsNullOrEmpty(excludeProperties))
      {
          excluded = excludeProperties.Split(',');
      }

      PropertyInfo[] properties = DestinationType.GetProperties();

      foreach (var destProperty in properties)
      {
          if ((!destProperty.CanWrite)
              || (excluded != null && excluded.Contains(destProperty.Name)))
               continue;

          var sourceProperty = SourceType.GetProperty(destProperty.Name);

          if(sourceProperty == null || !sourceProperty.CanRead)
              continue;

          destProperty.SetValue(destination,
                                sourceProperty.GetValue(source, null), null);
       }
}

Of course this could be made better by using Expression Trees – that would be more efficient than reflection, especially if this is done in a tight loop. But for one-time operations, this is good enough.

Filed in .NET | No replies

Tags: ,

Adobe LiveCycle – Collaboration

Published on December 8, 2011

In a Flex-based project I am working on, we needed screensharing, chat and whiteboarding capabilities for easy collaboration. After a lot of analysis, we decided to go for Adobe LiveCycle Collaboration, over other options such as Red5 server or integrating with Java-based components – primary reason being speed/cost of implementation and ease of maintenance and setup.

LiveCycle Collaboration is a service – which means there is no need for your customer to setup a server, and spend time and money maintaining it. The service does come at a price, but the first $15 worth of service/month is free of charge. We are still trying to figure out how much it costs us, but it does seem cheaper than the alternatives.

Getting started is easy, and there is some amount of documentation and sample applications. However most samples are based on the flash runtime, and if you want to use this in an AIR application, you are mostly on your own. There will be problems you will face on occassions, but the source code is open source, so it is possible to trace and debug. One of the most irritating problems, for instance, is that the screen-share add-in does not download and install automatically, as it does if used with flash web app.

Over next few weeks, I plan to write a few tutorials, based on my own experience in using Livecycle – particularly using the Chat, ScreenShare and Whiteboard components. I hope this will help others get to speed more quickly.

Filed in Flex | No replies

Tags: ,

User Generated Templates For .NET

Published on December 8, 2011

Jonathan just posted an article about using User Generated Templates for .NET, using Liquid.NET. It’s a good piece of info so do check it out!

Why this is important, is that this is a great way to introduce flexibility in report outputs, especially document printing. You know, printing invoices, certificates, letters, etc, which tend to be routine, only each company or institution wants it in their own format. Normally software vendors do a customization and then charge for the time and money spent, and they have to deal with the hassle of maintaining all this custom code through version upgrades and further customizations. Eventually it becomes a mammoth task, which only large companies can afford to pay for, and smaller companies either just start using pre-built templates, or stop altogether and go back to using MS Office.

We ourselves had this predicament when we started building Catalyst three years ago, and we dealt with it slightly differently. Our customers are less tech savvy than the average, and they just don’t have time to learn new template languages or dsls. So we used RTF templates – basically allowing customers to upload their own templates with a predetermined number of placeholders, which will be replaced at runtime. This gave us the best of both worlds and this is what we use so far.

However where this falls short, is that this ease comes at a price – flexibility is curtailed and we cannot use even slightly complex logic, such as flexibility in number of subjects for which marks are given, or number of lines an invoice is supposed to have – they can be handled, but each of these needs to be considered as a special case which again introduces complexity. I am wondering if we should go back and revisit that decision of using RTF templates, and start using a templating engine like Liquid.NET.

Filed in ASP.NET | No replies

Caching Data in Windows Azure

Published on September 15, 2011

Windows Azure has separate data services for storing persistent data, including blobs and tables. However one thing that an architect needs to keep in mind, is that each call to this data is charged – hence, if there is certain data that gets called repeatedly, then it makes sense to cache that data either in the local instance disk or a shared cache so as to avoid repeatedly accessing the same object from the persistent datastore again and again.

There are two ways to do this -

1. You could decide to use the instance local storage. This is useful if you do not want to use the more expensive RAM for caching. The most simple way to do this is described in this post.

Note though, that this memory is available only for that instance, hence if the next request goes to another instance, the data call will be made again. None-the-less it can be useful if you have a limited number of instances, hence the cost of accessing data store multiple times is smaller than having a dedicated cache.

2. You could decide to use memcached or the Windows Azure caching service, and use this common cache to store this frequently accessed data. Memcached makes a lot of sense to people who are already used to using this in other platforms, and Steve explains how to do this very well in his blog. This approach is both faster (due to being in-memory) as well as more efficient when the number of instances is higher.

Designing applications to work in the cloud needs us to rethink how we store and access data, and how we use the resources available to us – since everything is metered, making efficient usage of existing resources will directly result in cost savings, eventually impacting the bottom-line.

Filed in .NET,Windows Azure | No replies

Behavior Driven Development in .NET

Published on September 14, 2011

Behavior Driven Development is an evolution of Test Driven Development, that focuses on Use cases and tests that depend on them. Tests are written in a language that can be understood by a non-developer, which makes it easy for all stakeholders to review and contribute to them.

There are many tools that can help with doing Behavior Driven development in .NET. I recently wrote a post on InfoQ that elaborates all these details – do check it out!

Filed in Uncategorized | No replies