After the hackathon, I noticed that the .NET realm is not covered by the current Google+ clients. This prompted me to write a client to facilitate the current APIs. It is strongly typed, easy to use and pretty handy. I have included basic tests to describe it’s usage. Currently it only supports the API Key. Next is the OAuth 2. Check it out if you get a chance http://ping.fm/BqNtL
Ciao
a wise man learns from the mistakes of others!
This is a list of things that I have learnt in my stint in the IT industry. I thought that everyone knew these things but as is often the case we take for granted the knowledge we have gained via experience.
Everyone knows better than you.
This might sound sarcastic but it is not. When you come fresh out of your studies you figure that University or College has prepared you for everything. Every eventuality, every possible problem until you walk into your first job. What you fail to realise is that while studying you have been given the perfect environment to build programs. You are the only person responsible for your projects. Things can be configured and set up as you please (unless the assignment stipulates otherwise). Finally you never have to worry about the bottom line. By the bottom line I mean money. Sure you have to worry about marks but see how confident you are to make tough decisions that affect a companies bottom line. Listen to your peers, interact with them, make suggestions but be prepared to be corrected. You might very well have a good idea but it doesn’t fit the business problem. On the other hand you might have an idea that solves the problem. Business software development is a team effort. Be part of the team.
Learn when to keep quiet.
Don’t get precious about your project.
This does not mean that you are to take no pride in your work! What this does mean however, is don’t get so attached to what you have done that you refuse to improve it because it wasn’t your idea. Perfection is obtained through iteration. Nothing screams insecurity more than an individual who gets defensive about their code. Never forget that a software project is a strange beast, it can turn at the drop of a hat, hence all the agile methodologies now prevailing. These are not fancy management techniques but techniques put in place to help negate the dynamic nature of business and the rigged nature of software development. If you believe you are right, converse with the individual claiming there is a better way to do it. Perhaps they might educate or their reasoning might illuminate and angle you never thought of. Then again, you might very well educate the individual point what they believe to be a problem out.
Be professional.
Ok seriously. We have been potty trained. All of us. We have all figure we were old enough to rule the world and we most definitely thought we knew everything at some stage or another. That being said, why is it that when we first walk into the work place we become a bunch of snivelling cry babies? If faced with a difficult situation, evaluate it. Don’t throw a temper tantrum when you don’t get your way. Always remember that your employer is your client. You are a service provider, nothing more, nothing less. Do you job and do it well. If faced with a difficult situation tackle it. This is not only in the code base but also interpersonal relationships. If you have a problem with a fellow employee resolve it amicably. You guys, after all, are going to be spending a significant amount of time together. Deliver what you commit to delivering.
Be disciplined with your work. Check it before you submit it. Proof read the document before you submit it. Take pride in your project. The reason I said project as opposed to work is because their is nothing stopping you from continually checking the quality of the project. If you are a more experienced developer and you identify issues don’t just bounce it back to the developer. Take them time to help them fix. I have noticed that a significant amount of errors are due to a lack of understanding as opposed to laziness or stupidity. In this dog eat do world we have created we forget that we should carry the weak. Enable someone not to make the same mistake again, actively promote developer growth and maturing as opposed to bullying. The sooner they can do your job, the sooner your work load can be lightened.
You going to have to wipe your own bum.
I cannot tell you how often I have seen (and yes been one of them) guys sitting in their office fuming at the fact that they can’t do things better because their managers won’t let them. Remember that your working environment and your perception of it, rests completely in your court. If there is something you want changed and it doesn’t go against company regulations then change it. If you think there is something that will fix your development cycles and the risk is minimal to the project, change it. If there is a piece of code that you know can be better, or a piece of refactoring that would remove duplication without bubbling significant issues up the code chain then do it. Don’t expect your managers to hold your hands with everything. Be proactive. Identify issues and figure out how to solve them. There is nothing worse than someone that continually points out problems without a way to fix them. If you put yourself out there and make yourself noticed people will take notice. Don’t sit back and wait for things to happen. If you can improve things then do it. Just don’t step on toes or hurt people doing it. Hurting someone does not imply that you should not be honest with them. It implies that you should not be dishonest with them.
Fill the gaps you identify.
If you notice a gap, fill it. If you can assume a little more responsibility for the benefit of the team then do it. If the leadership needs help then provide it. Don’t just do what you told, do what you see is not getting done. Before you get all mad just take a minute and think about it. This statements does not mean working yourself to the bone. It means that if you can take up a little slack then do it.
It is a team effort.
As software development has matured so have it’s processes and methodologies. That being said, a significant number of old stable teams have been using a form of Agile before it became a catch phrase. Old stable teams have worked past all their teething issues. They have identified the optimal communication mechanism that they should use when addressing their team mates. They understand (you need to understand this so read it again if you have to) that the delivery of a section of the project is not the goal. It doesn’t matter how fantastic their piece of code is. If the project fails then the team has failed. Period. If your team does not produce the end result you have failed. Yes, don’t argue, no excuse, I don’t want to hear you did everything you were supposed to, you failed. End of story.
Be low maintenance.
By this I mean that you should be fluid. Adapt to your environments and situations. Look for ways to best fit in. Be a problem solver. Even if your solution is the best one, try and help. Refer to the first point though. There are ways to communicate your ideas without screaming and making a fuss. Don’t whine about things that annoy you, fix them or suggest ways to fix them.
Business is right.
Yes it is. Sure they know nothing technically but I got bad news for you. If business doesn’t make money, neither do you. As opposed to fighting business become an ally. Facilitate their requirements, even if they seem absurd. This doesn’t mean that they should dictate implementations or technology spaces. This just means that if they request a change then best we perform it. If they request a feature then best we create it. Business is an extremely competitive industry. Being first to market means a competitive edge. The more money business makes, the longer we get to keep our jobs. Lets work with them. The more flexible we are, I have seen this, the more flexible and understanding business becomes.
Get to know the network engineers.
This is something I learned very quickly because I used to be one of those guys. People, for some reason, see network and infrastructure engineers as the plumbers of the IT world. This could not be further from the truth. Remember that the machine you are working on, the telephone you use, the server you hosting on, the network transmitting all your data is because of these guys. If anything ever goes wrong you going to need them to help you fix it. If you are certain there is an issue with the network then take as much data as you can to the network guys so they can diagnose the problem quicker. It is absolutely incredible how busy they can become when you need them if you have been off towards them. I also find that network engineers are generally the funniest and comedic of any division in the IT industry. If you ever need a laugh, go chat to your network engineers.
I am sure there are more but this is all I can think of at this time. The reason I raised this is due to a discussion we had in the office today. If you want top excel then don’t be afraid to stand up and be counted. Fail fast, that way you can move onto the next thing. I have noticed that companies promote initiative even if the answer is not 100% correct. Believe in what you are saying, if you don’t then don’t put it out there. If you put your ideas out there expect them to get cut off. Be prepared to defend them but never defend them subjectively or emotional. Always back your statements up with facts or experience. If your idea doesn’t get accepted then don’t get down or think no one loves you. One day, grasshopper, you will have an idea that everyone loves.
If you don’t agree with the points above you will one day 
As I always say, I am always right, most of the time.
Well after the experience of the hackathon I would be lying if I said I wasn’t nervous about attending the developers day. I decided to go anyways and give Google a chance to redeem themselves.
well the day didn’t start off very well although the venue was superb. The keynote address was nothing short of uninspiring. The next segment regarding Android development was just as uninspiring. Being at a developers day I was expecting a slightly more in depth presentation regarding Android and not the usual stuff you can pick up anywhere on Google. After the first presentation I decided I was going to ditch the Android track and proceeded to the Google Application Engine (GAE) presentation, hoping things would get better but not expecting it to.
Well I was wrong! The Google Application Engine presentation was superb. Opening my eyes to a span of horizons regarding the technology (which I am not going to get into now). With a smile on my face I proceeded to the next mobile presentation which covered some stats. The audience asked some absurd questions that took up most of the presentation so I don’t think the speaker got to finish. I will get back to the questions in a second.
Once he completed his segment we started a code lab using HTML 5 and Google Chrome. YAY! Finally get to do some coding! It was super cool to code along to the presentation and watch the project start taking shape. At the end of the presentation we could finish the application and submit it. By submitting it we would put ourselves in line to win a Samsung Galaxy Ace (S5830). I proceed to keep my head down and complete the project.
Will working on the lab, the presentations continued around Google+ (eish) and some start up support project that Google is running with interviews and some inspiration stuff for those that are interested in starting their own business. Having tried this and failed miserably (due to some bad decisions on my part), I am fully aware of the pitfalls and pointers that these individuals were giving so I listened with half an ear. They have some fantastic ideas though, I am looking forward to seeing them come to fruition.
Anyways I carried on with the lab and finally finished it. Sitting around a friend of mine asked if I had submitted it for review. This was 20 minutes before the deadline! So I rushed off and had the guys have a look at the lab and they signed it off.
Anyways we got to the prize giving and two individuals grabbed what appeared to be two Samsung Galaxy S2 devices. Very cool! Then came the announcement for the winner of the Samsung Galaxy Ace. After going through the process of eliminating contenders, by God’s grace alone, I was chosen as the winner. I gladly accepted the prize but was then asked to demo the lab! I am not much of a public speaker, especially if I am unprepared but I did it anyway. I am not sure the audience understood what I was saying while running through the lab application but at least the one liner at the end got a bit of a chuckle. Oh and for the record, to all you Microsoft haters out there, my code lab was completed using Visual Studio 2010 and hosted on IIS 7.5. So there! Microsoft tools can also get the job done! The right tool for the job.
So all in all, the day was a success. Some surprises as to offerings by Google, who seem to also be adopting a cloud service offering and some really cool education regarding HTML 5
Thanks Google, for the time, the presentations and the prize. Only piece of advice I have is to perhaps include more labs, less rushed time slots and a little more food at lunch time 
As for the audience, I urge you to please formulate your thoughts before asking a question. Babbling along trying to create a question and sound intelligent at the same time just puts people to sleep. Make the question short and too the point. Give the speaker the opportunity to respond and leave it at that. Do not engage in a conversation with the individual, it is just rude and inconsiderate to the rest of the audience, if you want to explore your questions more in depth take it offline. Probably the most embarrassing moments for me (as a South African) was the questions around “What Google is going to do for the poor with regard to giving them mobile devices” and then the question regarding what Google was going to do about the fact that a 2 year old device wasn’t going to run the Android Ice Cream Sandwich (Android 4). Lets be honest here, 2 years in the technology space is a long time. I hate to admit it but it is. I also get upset with the fact that we toss out hardware like toilet paper but we cannot expect Google to make sure their Android OS is backwards compatible with the plethora of hardware vendors previous devices. Sure this was a Google Nexus device but let also not kid ourselves as to the maturity of the Android OS. It is a relatively new OS in the grand scheme of things and unfortunately if we are going to be early adopters these are the prices we are going to pay. Perhaps what we should do is petition the device manufacturers to work more closely together with Google.
Another thing to remember is that the more backwards compatible a piece of software is, the more bloated it will become. In the mobile space you cannot afford bloat. A mobile OS needs to be lean and tight. Doing only what it absolutely has to. With limited power we cannot go overboard the way we do with our personal computers. (This includes Mac)
Well I think I have pretty much covered everything and the next time I will 1) Prepare something for the Hackathon and 2) definitely attend the next developer day.Time to see if I can get a Microsoft developer day in somewhere as well
Thanks again to everyone that made today what it was and I enjoyed meeting those that I did and those that I didn’t, well maybe next time
Well I must honestly say I was very disappointed. Perhaps I expected to much or didn’t know what a hackathon is about but I didn’t picture it being what happened today.
From wikipedia:
“A hackathon, a hacker neologism, is an event when programmers meet to do collaborative computer programming. The spirit of a hackathon is to collaboratively build programs and applications. Hackathons are typically between several days and a week in length. A hackathon refers not simply to one time hacks, but to a specific time when many people come together to hack on what they want to, how they want to - with little to no restrictions on direction or goal of the programming.” http://ping.fm/XPwG6
Let me walk you through the day. We got there and made ourselves comfortable. It was hosted at Wits university and the venue seemed pretty impressive and I prepared for a good time with like minded people. Then it started. First we got a presentation from one of the GTUG members (Google Technical User Group or something). The presentation made me feel like I was back in high school being subjected to an English speech that was not prepared before hand.
Then we moved on to a video call from one of the Google developers in the UK or somewhere. Myself and others spent most of the time lip reading what the guy was saying as we couldn’t hear anything! So you sit wondering what you missing and people started getting distracted and then the whispering and conversations start. Things are going down hill fast. Video call ends and then we move on.
Next we get what can only be described as a whirl wind trip through using OpenAuth presented in Ruby. I still cannot remember anything from the explanation other than the individual presenting was a Ruby expert of sorts.
Moving one we were issued with the orders to build something using the Google+ API. Cool! Lets get cracking. Start investigating the Google+ API and get the fright of my life. The API only supports read requests. I kid you not, the social application said to be Facebook’s major competitor only has read access via the API. WHAT! So I mean really how hard can it be to make an HTTP request, receive a JSON formatted response and render that data. This is where things get really interesting.
I was under the impression that a hackathon was an event where everyone starts from scratch and starts nailing things together. How wrong I was. It seems that terms in the software industry are nothing more than marketing hype. Upon beginning development I started noticing that groups were getting ready to deploy their applications. What is going on here? Well it seems that there where a few groups who had actually developed their applications prior to the “hackathon” and merely brought them along to present. Now, again, I am not sure if I am just the idiot, but I am certain the title of the event was hackathon not exhibition? The event then proceeded to run an hour over time with myself and a few others extremely disillusioned about the entire event. Towards the end of the day I couldn’t help but look forward to being told the day was over so I could go home.
Sorry Google but I think you missed the mark with this one. Your Google+ API is wafer thin and offers nothing. If you are hoping to regain the traction you initially had I would recommend you start allowing developers to push and pull data from different applications and platforms. There is nothing that separates your social network site from Facebook and by virtue of the fact that the majority of the market is on Facebook, you really need to give people a reason to use Google+. I signed up for it with great expectations when it became available. Since then my usage has steadily decreased to next to nothing.
That being said, I am really hoping that the developers conference on Friday makes up for today because today was truly disappointing. That being said, the gapping holes in the API and client interfaces has given me an idea for a new open source project.
Right lets get cracking. First thing you going to want to do is grab the Jenkins files available at http://mirrors.jenkins-ci.org/. Select the package you looking for. The WAR file is the web application deployable to containers such as Tomcat or Glassfish. There is also a standalone version but seeing as I want to brush up my Glassfish skills I decided to grab the WAR file.
Now this is were I generally start getting extremely nervous. In my experience, deploying these things on app servers is always a nightmare requiring tweaking and additional work. So here we go.
In the Glassfish administration console, select the applications link. This will give you a list of currently deployed applications on the server. Right now I have zero 
So, select the deploy button on the grid header, select the browse button and navigate to your jenkins.war file.
Once you have done all this you will notice that Glassfish has conveniently detected that it is a web application, suggested a context root and an application name. Select the the item “server” in the virtual servers list and make sure “Enabled” is checked. Proceed to select anything else you want the server to handle. I just want to get this deployed so I am going to keep it minimal. Once you are satisfied click the “OK” button on the bottom right of the page. I was pleasantly suppressed to see that the deployment went off with out a hitch! If successful you will be returned to the Applications list with jenkins listed there now. On the right of the grid you will see links to perform actions. Select the “Launch” link. This will take you to a web page giving you the URL for the http location and the https location.
Click the link you want and wait for jenkins to perform it’s initial operations. If all goes well, you will be presented with the dashboard to perform your configuration and maintenance.
Just as a side note, having been involved with Glassfish 1 and 2 then slacking off during development of 3 I must admit that the level of the application server has increased significantly! I am very impressed at how the admin UI has been fixed and the ease of use and deployment. Hats off to the development team.
Oh, just as point, for those that think they have to go buy super powered machines, this box is running 1GB RAM with one of the first AMD 64 bit processors and runs fine, so now need to empty the wallet just yet Bear in mind that this is a personal machine so it isn’t subject to huge loads. Will do some stress testing and see where it gets me.
Other than that, have fun!
First things first. Lets get the downloads out the way.
Go grab java 7 from http://www.oracle.com/technetwork/java/javase/downloads/index.html
Then go and grab Glassfish 3 from http://glassfish.java.net/public/downloadsindex.html#top (I went with the open source edition)
Install Java 7 (you only need to do this if you don’t have a JRE 6 or higher). Then you need to install Glassfish. Follow the prompts. I left the installation location the same (c:glassfish3).
Next thing you need to do is navigate to c:glassfish3bin. I had to open the asadmin.bat file and edit it. I had to change all virtual references to physical references (perhaps because the environment variables hadn’t been set yet)
Next thing, open a command prompt and navigate to c:glassfish3bin. We are going to create a domain now, you can do this by entering the command asadmin create-domain. This will walk you through the domain creation process. Once that is done you can run the command asadmin start-domain. To verify that the domain has started navigate http://localhost:4848 (or change the port to the admin port you stipulated). If you see the admin console everything is running 100%
Next post I am going to explore deploying Jenkins http://jenkins-ci.org/
References:
http://glassfish.java.net/public/downloadsindex.html#top
http://blogs.eteration.com/blog/?p=494
http://www.oracle.com/technetwork/java/javase/downloads/index.html
Well, after a bit more research it seems that Microsoft does support validating outgoing messages. It still doesn’t resolve the issues in my post (http://kenneth.gotcheese.co.za/post/Microsoft-cannot-stop-being-a-rebel.aspx) but does answer where Microsoft feels any validation should be done regarding SOAP. On one hand I agree with them but on the other I disagree. They allow for the INotify property if you enable data binding but they can’t enable the max length on field? Strange I know but I suppose they have their reasons!
Anyways, you are able to validate the outgoing message against the declaring XSD. Again this sounds fine but has a few issues, namely those around exposing the XSDs for public consumption. I suppose you could get round this via HTTP authentication but that means you have to push authentication backwards and forwards. The other option is to distribute the XSDs with the client proxies. I see that the Service Reference created in Visual Studio 2010 does exactly this (after rewriting your XSDs for you 
).
To perform the validation you need to first create a client message inspector that implements the IClientMessageInspector.
Something like this:
public class MessageInspector : IClientMessageInspector
Once you have done that you need to implement the relevant methods (those that the interface declares).
The method we are going to focus on is the BeforeSendRequest method. In this method we will perform the validation using the XSD for the message. What you will need to do is check that the Message object is not a fault. If it is a fault return at this point. Next you want to get the Body of the Envelope. This can be achieved by calling GetReaderAtBodyContents()
var bodyReader = message.GetReaderAtBodyContents();
Next you going to need to get the XSD for your message. This might prove tricky if you have not got a naming convention that can be used to derive the name of the XSD. A way around this might be to load up the locations of the XSDs into a dictionary (perhaps even load all the XSD Schemas into that list so you can look it up via targetNamespace) but that I will leave to your imagination.
Once you have the body contents you open up the XSD file, load it into an XmlReader and read the XML document. If any errors occur, the callback method attached to the XmlReaderSettings.ValidationErrorHandler will be called.
First we configure the XmlReaderSettings:
var xsdPath = "pathtoyourfile.xsd;
using (var stream = File.OpenRead(xsdPath)) {
var schemaReader = XmlReader.Create(stream);
var readerSettings = new XmlReaderSettings
{
CloseInput = true,
Schemas = new XmlSchemaSet(),
ValidationFlags = XmlSchemaValidationFlags.None,
ValidationType = ValidationType.Schema
};
readerSettings.Schemas.Add("http://yournamespacehere.com", schemaReader);
readerSettings.Schemas.Compile();
//Attach to error event handler
readerSettings.ValidationEventHandler += new ValidationEventHandler(InspectionValidationHandler);
}
Then to validate the document you create an instance of a reader, attach the reader settings and read the document like so:
var wrappedReader = XmlReader.Create(bodyReader, readerSettings);
var startDepth = wrappedReader.Depth;
while (wrappedReader.Read())
{
if (wrappedReader.Depth == startDepth && wrappedReader.NodeType == XmlNodeType.EndElement)
{
break;
}
}
If there are any errors in the document they will be raised while reading and pushed to the callback handler.
For more information one solving this problem check out the references I found while solving it:
Well they have done it once again. Microsoft has never been know to conform to what the world of software engineering classes as best practises. They are also known not to confirm to widely published standards.
This is true in their Internet Explorer browser (although with the new versions they seem to be getting there) and other products. Yes I know that is how they make money but it is also the way they are losing a great deal of potential customers.
I was investigating the SvcUtil tool earlier and was asked to figure out how to enforce the declarations in the XSD limiting the length of string values. Now it would make sense for a client to support this right? Well not according to Microsoft. The XSD.exe utility also doesn’t support doing this.
The ONLY reason I can figure Microsoft didn’t do this is because they believe that the service should truncate and enforce the maximum lengths of the strings being supplied. While this might have you nodding your head going “ah yes, well then they have a valid point” my next question to you is, why is that valid?
Sure the contract needs to be enforced on the server side, that is a given. If it is not enforced on the server side it is not really a contract is it? However, does this mean that we should allow huge sets of string data to be transmitted if the first 250 characters are going to be consumed? I don’t think that is viable as you are polluting a call that was probably designed to be as efficient as possible. Still not convinced?
Well let me throw it back to the consumer or client. If you are generating a client for a web service and you have not explicitly checked the XSD will you be aware of the restrictions? Well you won’t if you haven’t checked it. Then next thing is this. If the validation of those maximum lengths has fallen to the client to verify, how are you going to do that? How are you going to know that string you are submitting must only be a length of 200 characters? The only way you can do this is to verify that the restriction exists inside the XSD and then implement some sort of check on the field with a message letting you if the max length is exceeded.
While this might seem like a viable solution, I am incline to disagree. There is a significant amount of work attached to doing this and if the contract should change for what ever reason, you will have to go back and find all the places you have implemented this.
I will be contacting Microsoft with regard to this and try and figure out their thinking behind it and if there is a road map to fix it. Until then, if you have any ideas or suggestions please let me know.
YAY! I finally got myself an airsoft rifle care of the folks at http://www.kreature.co.za. Full metal so it weights roughly 3kgs which is really neat (don’t really enjoy the plastic ones that feel like I am carrying a water pistol). My initial impression is that it is pretty neat. It doesn’t quiet have the resonance our presence as the real one (but you can’t go around discharging AK 47s randomly unless you are in some North-African countries) but it seems to work cool.
Lets have a look at a couple pictures shall we?
First up the rifle with the two point sling mounted and the stock extended
Pretty neat huh? Next we take a look at it with the stock folded (still with the two point sling)
Right my next challenge was charging the battery. I found a really cool site that describes the formula for charging the battery. The formula goes like this:
(battery capacity (battery's mAh rating)/charger output (mA - usually written on the charger)) x 1.4(for NiCad batteries, 1.5 for NiMh batteries) = time (in hours).
You can view the rest of the discussion here : http://answers.yahoo.com/question/index?qid=20091013093650AAcTEBp
So I worked mine out and it needed 4 hours according to the formula. So I charged it for four hours and went outside to have some fun. The battery died in 5 minutes 
So I remembered that some batteries require a longer initial charge. So I gave the guys at Kreature a call and asked what the story was. Seems the Ni-MH type batteries require and initial charge of 8-12 hours! Ok well at least there is nothing wrong with my battery. So now it is plugged in again and this time I will leave it for 10 hours.
Anyways, still very excited to finally have it (been trying to get one for over a year now!) so waiting a few more hours ain’t going to kill me. Now it is time to start finding some games!
