Posts

Showing posts with the label C#

Uber's Michelangelo vs. Netflix's Metaflow

  Uber's Michelangelo vs. Netflix's Metaflow Michelangelo Pain point Without michelangelo, each team at uber that uses ML (that’s all of them - every interaction with the ride or eats app involves ML) would need to build their own data pipelines, feature stores, training clusters, model storage, etc.  It would take each team copious amounts of time to maintain and improve their systems, and common patterns/best practices would be hard to learn.  In addition, the highest priority use cases (business critical, e.g. rider/driver matching) would themselves need to ensure they have enough compute/storage/engineering resources to operate (outages, scale peaks, etc.), which would results in organizational complexity and constant prioritization battles between managers/directors/etc. Solution Michelangelo provides a single platform that makes the most common and most business critical ML use cases simple and intuitive for builders to use, while still allowing self-serve extensibi...

Flyweight Design Pattern

So you have a group of objects that can be reused, but each time you use one you have to create it first. The problem is that instantiating these types of objects is expensive, and you don't want to instantiate the same kind every time you need it. Enter Flyweight design pattern. With this pattern, the trick is to create a new object only when you've never created that same type of object before - if you HAVE created it before, then simply look it up and use the one that's already instantiated. Here's some code: public class Flyweight { public static Dictionary _Table = new Dictionary (); public ISomething GetSomething(int key) { ISomething something; if(_Table.TryGetValue(key, ref something)) { return something; } else { something = new Something(key); _Table.Add(key, something); return something; } } } What this code does is ensure that t...

Factory Design Pattern

Image
The factory pattern is used when you want to separate the creation of objects from where they'll be used. For example, say you have one object that must get a Triangle object and draw it on screen. It doesn't care about what the triangle's state is, just that it has a void Draw() method. Suppose further that you have many types of triangles, and they can all be 'drawn' onscreen. In order to separate the creation of triangle objects from the caller, we would use the Factory Design Pattern: 1.) Create an interface called ITriangle, with one method : void Draw() 2.) Have all types of Triangle implement ITriangle. 3.) Create an interface called ITriangleFactory with 1 method: ITriangle GetTriangle() 4.) Create a concrete 'factory' class for each type of Triangle, each of which implements ITriangleFactory, and returns a new instance of their respective triangle in their implementations of GetTriangle()...since each Triangle type implements ITriangle, ...
Today I populated an html div element asynchronously using jQuery and JSON in my ASP.NET MVC2 project. Now, when you were 10 years old, did you think you'd one day find a sentence like that above interesting? I bet not. But here's why it is (lol) : In MVC you're allowed to mix javascript code (client side) with C# code (server side), but you have to understand where each part of it is being run. Here's the code (the important parts of it anyway): Client side (mostly): <script type="text/javascript"> $(document).ready(function() { $.getJSON(' ', function(jsonData) { for (i = 0; i ?serviceAddress=' + jsonData[i].serviceName, function(data) { $("#mainDiv").append(data); }); } }); }); </script> Server side : public class DiskSpaceController : Controller { public JsonResult ...

Mono for Android

Image
I'm excited. I've recently been looking for a way to motivate myself to learn better software development practices, and stumbled on something called mono. No, I didn't get it from kissing someone. Mono for Android is sort of a Visual Studio plug-in which allows one to develop Android applications in C# ! I'm SOOOO happy about this. Personally, I learned Java in school and tried out Android development for a couple weeks, and liked it. Unfortunately, Java is going the way of the dinosaur, and it seems that .NET is taking it's place. That's why I decided to pursue learning C# instead of Android. Now that mono has arrived and (hopefully - I'm updating the API's as I type) works, I can pursue BOTH Android development AND .NET ! Basically this means I can get good at working for the man, and developing for myself. I'm super excited. For a brief history of mono's inception, check out this blog: http://www.koushikdutta.com/search/la...