xsights is hiring
We are looking for:
- Server Side Developer
- Web Developer
- Junior Developer
All the jobs are located in Israel.
If you are interested send a mail to jobs at xsights dot com
Here are the jobs description:
Server Side Developer
Position Description and Responsibilities:
We are looking for a motivated developer, a team player, who can improve and add features
to our product, focusing on a distributed environment with technology challenges.
Improve performance of existing components by clustering, messaging, caching etc.
Integrate with external services.
Requirements:
- At least 2 years experience in C#, understanding OOP principles - must
- Experience in concurrent programming - must
- Experience with communication protocols (TCP, UDP, WCF) - an advantage
- Experience in Unit Testing - an advantage
- Knowledge in Distributed Services and Technologies, such as Hadoop, ActiveMQ - an advantage
Web Developer
Position Description:
We are looking for a motivated web developer for our distributed system, to improve and add new features to the inner admin site and to the company’s public beta site.
Responsibilities:
Web site development and deployment Server side programming in a distributed, challenging environment, in C#/Python/Ruby
Requirements:
At least 1 year experience in C#/Python/Ruby - a must
At least 2 years in web development with full understanding of development and deployment process:
Client Side: HTML, CSS, JS, upload using a Flash Uploader (such as SWFUpload), Ajax, jQuery.
Server Side: IIS and ASP.Net or other web server and technology Django/Rails/ASP.Net MVC - a big advantage FTP deployment - an advantage DNS settings - an advantage.
Junior Developer
Position Description:
We are looking for a motivated developer, a team player, who can program tools and tests in C#/Python, for acceptance/system tests of our distributed system. A creative and responsible person, with broad thinking.
Responsibilities:
Create an automated testing environment
Find and pinpoint problems
Code solutions
Requirements:
Experience in C#/Python - must
Experience with HTTP protocol - must
Experience in monitoring tools (WireShark, Fiddler) - an advantage
Experience in Unit Testing - an advantage
Knowledge in Distributed Services and Technologies, such as Hadoop, ActiveMQ - an advantage
Announcing Sniptwit
Few weeks ago, I came up with small extension method for the monorail web framework:
1: public static class RequestExtensions
2: {
3: public static bool VerbIs(this IRequest request, Verb verb)
4: {
5: if (request == null)
6: return false;
7:
8: return request.HttpMethod.Equals(verb.ToString(), StringComparison.InvariantCultureIgnoreCase);
9: }
10: }
This makes monorail a little more REST friendly as it is easier to work with http verb.
This small snippet obviously does not justify a full blog post, so I thought – twitter is the place to publish it!
I started looking for a service similar to twitpic for posting code snippets on twitter. Unfortunately I could not find one.
So I decided to create one! I decided it is a good opportunity to learn google app engine and now sniptwit is up!
Sniptwit is simply a site for posting code snippets on twitter. You can login using your twitter account with oauth (so you don’t share your password), paste your snippet, write your status update which can be a description of the snippet and post it to twitter.
Have fun!
Integration testing with the help of CherryPy
The time for integration testing for a system I wrote arrived (let’s call it system A). In essence, It is a backend system which performs a series of operations (steps) and if all went well, the last two steps are deployment of files to a server and then notifying a system (system B) on the server to refresh its state by reading the new files.
The notification is performed by an HTTP call. Btw, the HTTP interface for system B is the one from here.
In order to test the system A end to end I needed it to perform all the steps, including the notification to system B. To achieve that, a running system B should be present, however, it is quite an over-kill to run system B just for testing and then checking that the call was received.
The simple solution for that is just to run a mockup of system B that has the same HTTP interface.
Naturally I thought about putting an ASP.NET mockup as I am a .net guy. This however requires configuring IIS, playing with the web.config file and of course there is the problem of the url which I can’t simply control…
In order to avoid this whole overhead I went and wrote a simple mock up using CherryPy and Python (Ruby’s Sinatra would be an even better fit however I am little more familiar with Python).
It took only 8 line of code (not including blank lines) to implement this:
import cherrypy
cherrypy.config.update({'server.socket_host': '0.0.0.0','server.socket_port': 50002,})
class Root:
def ReferencesUpdate(self):
cherrypy.response.headers['Content-Type']='text/xml'
return "<ServerResponse><Success>True</Success></ServerResponse>"
ReferencesUpdate.exposed = True
cherrypy.quickstart(Root())
And that’s it! I have a web server up and running!
Thought: Extensible twitter clients
I just wonder why none of the twitter desktop clients out there does not support plugins?
I mostly use Twhirl and I would expect an option to plugin things that work the same way as the built-in twitpic support.
I checked TweetDeck, Spaz and Blu too but they do not plug-ins as well.
TDD == Demoware?
Maybe this is just a feeling only I have but TDD at its purest form is kind of demoware. Why do I say this? Well, take a look at all the TDD tutorials out there - it will usually be the chewed-up email sender or money transfer between accounts or some kind of blog. All of these are very narrow examples which are for, well, demoware…
Non of the examples above are of applications with a “big picture”. I find that TDD is not suitable for big pictures because when the picture is big, I can’t see the whole of it - I have to make some assumptions that I know are going to change soon. This is just something I have to do in order to control complexity and be agile.
When these assumptions change, code is going to change and in case I have tests, they have to change as well which means I had more code to start with and I have more code to change and this excessive code served no purpose! (since it had to change as well…)
Saying that does not mean I think tests are not important - I think they are important. Same goes for the design principles that TDD promotes such the SOLID principles - they are important.
I think that the shift to BDD strengthen my point as well.
So what do I propose? Quickly develop the first generation of your application. By that you will learn how your application should behave. With the insights you have gathered, write the tests for your application and refactor. I believe that way the test code will take less time to think about and will change less frequently.
SoC - The Plug-in way
Soc (Separation of Concerns) is one of the fundamental OO principles I try follow.
In a recent feature I implemented, I had to add a management operation through http. Our system exposes a management http api that supports operations such as restart and shutdown which are pure management operations the effect the system as a whole.
Our system is a SOA system in which the management component, called WatchDog is responsible for tracking and maintaining the health of the services without caring about the nature of the service.
The new operation however, tells just one component to refresh its state. It is a specific component and knowing the component, how to contact it and tell it what to do just felt wrong to add to the WatchDog’s management api - it will break SoC since now the WatchDog will know and handle things it is not supposed to.
After some thinking, I decided to solve this problem by introducing a simple plug-in mechanism to extend the http management api.
I added a url mapping to the management http api. Every call with the following pattern:
http://myhost/management/{pluginName}
Is mapped to a method on a wcf service which will look for a preconfigured plugin with that name and will invoke it. The mapping was declared as follows:
[OperationContract]
[WebInvoke(Method = "POST", UriTemplate = "/management/{pluginName}")]
ManagementOperationResult InvokePlugin(string pluginName);
Currently the plug-ins are simply pre-configured by code and are available through the following interface:
public interface IPluginProvider
{
IEnumerable<IManagementPlugin> GetPlugins();
}
The interface for a plugin is this:
public interface IManagementPlugin
{
void Plug(IPluginServices services);
ManagementOperationResult Execute();
}
The Plug method “hosts” the plugin and the Execute method is used to invoke the plug-in and returns a result that is serialized and returned to the calling client.
Thanks to this approach, the management system can be extended without having to know stuff it should not know. All the operation specific behavior is fully implemented in the plug-in and the Separation of Concerns is kept.
Resharper does not promote IoC
Posted by reshefm in Uncategorized on September 3rd, 2009
I just upgraded to resharper 4.5 and got this note:
It is never instantiated since I use IoC container 
Added custom conversions to ConfigReader
Posted by reshefm in ConfigReader on July 29th, 2009
I added the ability to define custom conversions to ConfigReader.
You can read the documentation here.
Thoughts about Resource Oriented Programming
This is a brain-dump of some thoughts I have about Resource Oriented Programming/Architecture.
- Unlike OOP in which associations are managed in the objects level, when focusing on resources, the associations are managed in the resource representation, such as using hypermedia’s anchors to link to related resources.
- Resources are mapped to DDD’s Aggregate Root. Inside the aggregate, association to other aggregates should be (/translation should be) supported by the environment like openrasta CreateUri extension method).
- I think OO and RO have different scopes. RO is on the protocol level (it supports rigid and simple interface) - it is the entry point to the domain - the way to manipulate it. It is also not the necessarily the best solution as an entry point. It just fits very well to web applications as HTTP is about resources. Objects on the other hand are a very flexible protocol, this makes them very convenient mean to manage the internal domain but they can be confusing as the external protocol.
REST Resources
When I first heard the term REST and read the wikipedia article about it (which was updated since I first read it) but the impression I got was that REST is about having friendly URLs and using verbs as the way to describe what you want to do.
Only lately I got referred to to this article by my boss, Arnon:
http://www.infoq.com/articles/webber-rest-workflow
Which is a really excellent explanation and example of using rest for integration over the web with emphasis on using http as a state machine (what is known as HATEOAS), usage of the HTTP response codes and HTTP headers and conventions of HTTP verbs (GET, PUT, DELETE are expected to be idempotent).
Reading this article really placed the puzzle pieces in place for me.
Another excellent resource is this presentation about REST patterns and Anti-Patterns.:
With my current knowledge of REST, it really amazes me that for so long I was using the web just as means for tunneling without really harnessing its power. The shift to thinking about entities as identifiable resources that their state can be changed by web calls really simplifies the way I thinks about web applications.
