Google+ C# client

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 fool doesn’t learn from his mistakes, a smart man learns from his mistakes and …

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.

1. Your opinion counts. Really it does. When you express it is a different story. There are times to speak and times to keep quiet. If you are not sure whether it is time to speak or time to be quiet then it is probably best to be quiet. Don’t be afraid to speak though but before you speak, formulate your questions. Think about what you want to say and what you are trying to get answered. When you do speak make it concise and to the point. Leave no room for ambiguity. Don’t ramble or speak for the sake of speaking. Nothing turns people of your statement, no matter how smart it is, quick than rambling or disjointed statements. I often remind myself “Light travels quicker than sound. That is why people appear intelligent until they open their mouths”.

 

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.

Google South Africa 2011–Developers day

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

Google Hackathon South Africa 2011–Why Facebook will pwn Google+

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.