Author: sshadmand

Google Labs is Shutting Down :(

Early on in transformation into an official entrepreneur I began preaching the benfiist of focus, and the trap that any small task will invariably have the potential to become a time suck from what you should be spending brain cycles on instead (what has now been known as ABBA in our circle). But I am still left with a small sense of saddens to find out that Google Labs is shuttung down. 😦

Check out the list of many of the apps that will be phased out, and find those are already gone: http://www.googlelabs.com/

It was a good feeling to know that Google maintained their, seemingly altruistic, attention to the experimentation of new ideas for the sake of simply knowing more, and fixing our uneeded hudles in data through tech and science. They were the “casual NASA” of our dat, and althought I understand the need to focus, I had always hoped Google would remain the exception to the rule, and give us something to map our ideals to.

Farewell Google Labs, I hope what you represented does not fall by the wayside in your company or our tech community as well.

A new take on flight: One wing is all you need.

Check out this video. It’s kind of geeky, well it’s very geeky, but still neat-o. These guys at lockhead took a short break from creating deadly weaponry and re-invented flight.

From divincis screw shaped helicopter, to the right brothers wheeless test flight, flight has been a display of symetrical balance. Most likley due tothe need to ma the air craft as part of the prerequisites. But as unmaned aor craft becomes moreand more of a mission of our miltary, the premises are thrown out the door, and the ability for our engineers and deisgners to get creative beings in the begining of a new era of what we see as flight.

Here, the helicoprter-ish-one-winged-airplane spins in cricles to achive all raged of motions, as well as take of and langing. With this design laucnhng by flingin
 the aircraft into the area is also a falry easy manuver. 

Socially Non-Social

We always search for strong connections, but I am fascinated with the sociological need to be surrounded by those you don’t necessarily want to share a strong or long term connection with. But, at the same time, you still feel compelled to be around these people; being social without socializing. An empty dining hall seems stale, a crowded one seems more inviting, and one is more favorable over the over without having the intent to interact with any one individually. Maybe it is because you know you are all there for the same purpose as you that draws us to those situations . Is that enough to feel connected, be intrigued, be involved? How can that be productized?

To date, the majority of what we see as or interaction trails are signified by actions around our usage of some “thing”. An action is usually meaningful on it’s own, like friending, commenting, sharing, or liking. But just the other day I sat by myself in a crowded jazz lounge by myself and although I did not make any meaningful conversation with those around me, I still felt like I did *something*, that I was involved. And  without a single action. Why do those feelings exist, and how does that transfer to the online product world?

Well, I guess it feels most like I left a trail of existence, that others can share with me, behind. I am allowing myself to be observed and observing others around me that share a similar interest. Our trails intersect and interact even when we don’t. So why can’t this trails be used to provoke action instead of focusing on having specific interactions provoking observations? My trail is left behind, the fact that I was interested, observed, and left, has a signifocance that the online world can benefit from. As new trails are created, other trails are attached. I displayed the fact that I observed something of interest to me in a group setting by being there, and I allow others to observe that fact. I allow them make a decision to attach themselves on to that trail, or create a trail similar to mine (or vice versa.) I left behind something, whether I did something of any real significance with my interactions or not.

I am most intreuiged by the phenomenon that surround these facts of social nehavoir. Socially non-social, strongly connected without heavy interaction, high emotional social gains without longterm commitments. These are some under appreciated parts of our everyday life as social beings. These situations need to be represented with more attention in our online world.

Short Cycle Scrum: A leaner, meaner, scrum.

Here is a summary of how we implemented a leaner, more efficient Scrum at Socialize coined Short-Cycle-Scrum. We have added some rules of thumb, and processes around ou Scrum to deliver stories with a surprisingly good amount of efficiency. This is a style we have specially tuned for short sprints (usually one week.)

Short Sprints Cycles
Sprint plaanning meetings can go long. They should definitely go as long as the need to, but no longer. One of the main reasons to have a sprint planning meeting at the beginning of yur sprint with the whole projects team members is that having a system that relies on having meetings throughout the week are like death by a million paper cuts for each developers time. Many times, those metings throughout the week are unfocused, not involving all the members of the team needed, and breaks up a developers day. most likley one devlopers need for a quick meeting means another developers inability to focus on delivering their story. So, with a single, team wide, sprint planning meeting you take care of all the discussions scheduled for your sprint as a team, all at once, when every one is in “meeting mode”. The goal is to get as many questions out of the way as possible. By the end of the meeting all your developers should be confident enough to solve their own questions or problems, as much as they can, throughout the sprint. If your sprints are short enough, and your stories are as atomic as possible, your devs will never truly implement something so wrong, due to a quick judgement call, that can truly ruin your the product. They must make judgement calls on their own to get the story delivered, this will get features out, allow for interative improvements, and avoid analysis paralysis.

A good rule of thumb is: If you can’t do it in a week (or your sprint’s time span), it is a sign that the story should be smaller. This takes a little convivcing when going over new features or stories with your team, but for us, even if at first it does not seems so, it ends up being the case time after time.

This and Next Sprint Need Only Apply

Another way we have made our planning meetings even more efficient is by asking the team to only address issues in terms of “this sprint” or the “next sprint”, every other situation can wait. People have a tendancy to use planning meetings, their PM tool, and stories to “remember” things that are”needed”. We have found that things that are truly needed are rarely forgotten and adding them to the plan do nothing more then create noise. If the concept or feature will take more than 1 sprint or is something that needs to be done, or done at a later sprint, then create a thread or discussion abut it, but do not take up sprint planning time, or your queue with it.

Asynchronicity and Simplicity

Using sharable threads (for us we use basecamp) for asynchronous conversations helps us hash out discussions, and preserve the sprints for only things that are ready, or close to being ready, for implementation. This helps your team sperate planninng and ideas, from implementation and delivery. A good tip for a synchronouse discussions is to make sure new threads are created for new topics and that the title of the thread is the topic to close and focus on. Again, only after there is a clear concept formulated and ready/need to be implemented in tis or the next sprint, should it be added the icebox or queue.

Planning Meeting Agenda

So how do we set up the agenda for the next sprint so we know what to talk about? We create a sharable doc that devs can add the link to a story they want to delve into, or they want moved from the ice box into the backlog or sprint. Again, only things that need to go into the next sprint are added here. At the sprint planning meeting we go over the sprint we are starting, and maybe a few stories into the backlog, just incase we have a high velocity week, and then links added to the sprint planning doc. This keeps the sprint plannig meeting tight and focused and works very well for short sprints.

Tools

We use pivotal tracker and google docs to manage all this, and base camp for discussions and group notifications. I will go more into the use of these tools in subsequent posts.

Summary

The main take sways: if it is not for now then it does not exists in the panning world. And discussions together things onto the planning world should be as asynchronous as possible. Finally, completely sperate high goals with systems that are used for accomplishing the next step.

An ethical rule of thumb

History has a way of repeating itself. I try to keep myself objective about todays events and ethics, so I am able to rise above the norm and into the right.

Apply what you believe in today: how your perceive morality, ethics and kindness, and apply it to the past, 200, 100 and 50 years. Would you be in what history has decided was good or evil? In what we now see as right or wrong? That should tell you how the future will look back at you, and help guide your perspective on how you see the world today, allowing for some objectivity. This extra step in your thought process while making descisions about morality and ethics in today’s current events, could help prevent you from becoming the great grandfather or grandmother no one wants to talk about in public.

There is one extra step to make this ability to predict how the world will view your stance on current issues in 100 years+. you have to recognize the general terms in which a situation is defined. For instance, racism is not a question of race, but about human equality, poverty is as much about greed and sharing than it is about finance, science is a question about asking questions and challenging systems as much as it’s about what is “proven”, and culture is more about fear of the unknown than it is about what you beleive is right or acceptable.

Release Notes Generator (For Pivotal Tracker)

Here is another quick tool built on GAE. It takes all your PT stories and bugs, scrapes out chores, and release stories, leaving a listof features and bugs available to copy and paste in to your release notes, emailer, or README file.

Often departments always asking if a release is out, what features are included, and if it is not out how long until it is. This tool will also print a header letting the person using the tool know if the release in question is out, and if not how far down the pipeline it is.

To use the tool most effectively you should check out my post on releasing versions through PT. (coming soon)


Download RNG for PT


Or fork and contribute on GitHub

Team City Monitor (with coverage history) for GAE

Per my last post about the splendor of GAE, below is one example of a tool I built for us at Socialize to keep an eye on code coverage and lets the group know if a build is broken (if our tests have failed.) This script is built to run on Google AppEngine, checks against a TeamCity Server install, and expects that each project in team city has code coverage outputted to its artifacts folder.

What is C.I. Server and why is it important?

C.I. stand for Continuous Integration, and is a system used to constantly/”continuously” checks to see if a code base is “working” or not. Team City (by JetBrains) is a product made for that process. Usually it is used to run tests against a code base to make sure it is working as expected, as a part of the QA life cycle. These tests are made up of “unit tests” that are created by the developers whom write code to test the code they are writing. It can be a bit odd for those that have not ever done so, but it is quite important when trying to deliver stable code. In short, and in its simplest form, this whole system makes sure new code/changes doesn’t break old code already in place. You can read more about these processes and purposes here: Unit Testing & Integration Testing.

What is code coverage, and why is it important?

Code coverage examines how much of your code is being tested. For instance, you may have a C.I. system in place, and a unit test frame work running within it, but if the tests only test/”cover” 1% of all of the code you aren’t really delivering a level of confidence you should be. In this tool we track the coverage percentage over time. Seeing it as a graph helps recognize dips in coverage easily.


Download Team City Monitor for GAE


Or fork and contribute on GitHub

Leave the caves and create your tools!

GAE offers a free to get started approach, along with an instant “hello word” initial environment, making sandboxing ideas and building helpful tools for productivuty a snap.

To get started, download GAE, press the plus sign in the bottom left corner. Set the directory you would like to work out of and your almost done. Well, at least you are already at the stage you need to be to start playing with the system locally, in what we call the development environment (No one can see your system but you.) Just hit the [play] button on the GAE dashboard and you are running with your first environment. Just click the Browser (the compass looking thing), or go to http://localhost:8080 in your browser, and you should see your first “hello word“! It is quite reassuring to see it work so smoothly (if indeed it does), and if this is the first time you have coded, trust me they have taken out a hell of allot of pain out of the tedium it can take to get here.

Without getting into the nitty gritty of code just yet, let’s push your baby to production (That means make it live/accessible to the world). That’s right, you are about to push a web application live to production!  First create a new app at the google app engine home page and follow the steps there (setting up your yaml for upload). Your yaml file tells google which app your are updating when you do so. Not making sure your yaml matches your project is like  you sending mail through the USPS without out a “from”/”to” address.

Once complete, press the blue arrow pointing upward (the “deploy” button) and it will deploy (AKA: push to prod, go live.)

Once deployed, you can update, monitor, or even share you application with the world. And all for free. Not that this baby would get allot of attention in its current state (just a “hello world”), but if it did, it would also be scalable. I mean 10 years ago this would have cost you quite a bit of time money, especially if you didnt know allot about server configurations, apache, linux, or windows server, or…well you get the idea.

There are a few sample apps you can play with on the GAE site. If you are ready, start developing some code i Python. Maybe had a hellow world message of your own.

When you start feeling saucy, try and create a model. A model is a data structure you can save, or persist, data to your system. Again to you newbies out there, this is the equivelent of your granfather telling you, “back in my day I had to walk up a hill in the snow to get to work, and up a hill in a blizzard to get back.” Setting up a database on a production server was a skill on its own, but to create one that is scalable, and without the need to architect it is amazing. You see, based on the models you create GAE intuitivley creates your “database”, stores it efficiently, and assumes where indexes need to be placed. You really don’t have to understand any of this, but if you want to you can look up those terms have at it: indexing, database, architecture, MVC…. Like I said, I’m just an old guy complaining about hills.

If you are still a bit timid about getting started, don’t worry there is a baby step in between these tween sized steps that can help you get ramped up before you start churning out lines and lines of code. Click on the “SDK Console” button on the GAE dashboard. It will open up a web page that is running locally, on your stage environment, that gives you windows into your system to hack around with. (This console lives inside your development app, so don’t forget to run your new app to get access to it.) Once in the console, click “Interactive Console”. There you will have a very rudimentary terminal that you can write temporary test scripts in. The output is shown on the right of the screen. This is a great place to get errors, make mistakes, and go nuts! (Note: The SDK Console also houses your development DB, so you can check to see what data you are saving after you have attempted to save it.)

Note: The easiest way to get started as a newbie, in my mind, is by using Python in GAE. Java, although awesome, is a bit more advanced.

I recently used GAE to create a few projects to help out the team. One for TeamCity monitor to view coverage reports and if a build is broken or not. And also one for Pivatol Tracker to help our press and marketing interpret what is coming out of the product pipeline, if its ready, and what are the stories of value within. I will post templates for those projects in the near future.