Questa news è stata presa dal Blog di Habbo.com! In quanto tale abbiamo deciso di non tradurla, ma di lasciarla comunque pubblica per gli interessati!
Since the first post on this blog we’ve had lots of requests for there to be some kind of ‘A day in the life of’ blog, discussing some of the steps and stages of development here at Habbo. So today I will be walking you through my average day! We’ll be looking at a small – but mighty – feature that went live last week; When a user reports another Habbo, the reported Habbo will be automatically muted.
So what’s first?
After walking into the office, helping ourselves to a cup of java goodness, and pondering about the exciting things ahead, we sit down and check our emails! Basic, but important. We need to know what’s been happening in all the different Sulake departments before we have a daily dev (development shortname) meeting. At this meeting we discuss any new problems or issues that might be occurring, as well as keep each other updated on our other projects progress.
Once the meeting is over, we can move on to the more interesting stuff! We log into some of back systems, check on how the hotels are doing. We typically tend to check on what’s been deployed recently, what’s still being worked on, and if they’re any new bugs that have been reported.
Below is a little graph showing the number of issues reported in 30 days vs the number of issues fixed in 30 days. Those with a eagle eye will notice there are more resolved than created, this is because we also fixed issues reported more than 30 days ago within these 30 days!
Great.. but I haven’t seen any coding
Before we can start coding we actually need to put in a lot of preparation into a plan for the feature. Even something as seemingly small as automatically muting a user after you report them takes a large amount of pre-planning.
For instance, for this particular feature we first had the user care team contact us and say “Hey guys, we’ve got this idea for an amazing new feature.” Once we have that initial concept, we have a lot more questions to answer before we can proceed; How long will it take? Is it actually possible? Does the feature exist already? Is there a better alternative? Who is going to work on it? …and much much more!
Once we answer all of those, then someone on the Development team starts working on it. S/he develops it locally on their machine – this is where coding gets involved! Then once they are happy with the feature, they test it and then publish the feature on one of our testing hotels. Only Sulake staff have access to these not-so-top-secret testing hotels. Once the feature is live on the test hotels, a number of different staff from different departments will test the feature. We wouldn’t want to publish something that wasn’t the best it could be!
So when does it get onto Habbo?
Well that’s a good question. After a large amount of testing has been done, and any required localizations have been completed, we start preparing the live hotels for the new feature. Typically, this is when a number of different fansites start to pick-up on the new features and will comment and report on them.
Is that it?
Well, not exactly…. There are many smaller stages involved, such as code reviews and documentation, but for the most part this is it! We hope this brief overview will give you a good idea of how feature development work happens in Habbo!
Since the first post on this blog we’ve had lots of requests for there to be some kind of ‘A day in the life of’ blog, discussing some of the steps and stages of development here at Habbo. So today I will be walking you through my average day! We’ll be looking at a small – but mighty – feature that went live last week; When a user reports another Habbo, the reported Habbo will be automatically muted.
After walking into the office, helping ourselves to a cup of java goodness, and pondering about the exciting things ahead, we sit down and check our emails! Basic, but important. We need to know what’s been happening in all the different Sulake departments before we have a daily dev (development shortname) meeting. At this meeting we discuss any new problems or issues that might be occurring, as well as keep each other updated on our other projects progress.
Once the meeting is over, we can move on to the more interesting stuff! We log into some of back systems, check on how the hotels are doing. We typically tend to check on what’s been deployed recently, what’s still being worked on, and if they’re any new bugs that have been reported.
Below is a little graph showing the number of issues reported in 30 days vs the number of issues fixed in 30 days. Those with a eagle eye will notice there are more resolved than created, this is because we also fixed issues reported more than 30 days ago within these 30 days!
Before we can start coding we actually need to put in a lot of preparation into a plan for the feature. Even something as seemingly small as automatically muting a user after you report them takes a large amount of pre-planning.
For instance, for this particular feature we first had the user care team contact us and say “Hey guys, we’ve got this idea for an amazing new feature.” Once we have that initial concept, we have a lot more questions to answer before we can proceed; How long will it take? Is it actually possible? Does the feature exist already? Is there a better alternative? Who is going to work on it? …and much much more!
Once we answer all of those, then someone on the Development team starts working on it. S/he develops it locally on their machine – this is where coding gets involved! Then once they are happy with the feature, they test it and then publish the feature on one of our testing hotels. Only Sulake staff have access to these not-so-top-secret testing hotels. Once the feature is live on the test hotels, a number of different staff from different departments will test the feature. We wouldn’t want to publish something that wasn’t the best it could be!
So when does it get onto Habbo?
Well that’s a good question. After a large amount of testing has been done, and any required localizations have been completed, we start preparing the live hotels for the new feature. Typically, this is when a number of different fansites start to pick-up on the new features and will comment and report on them.
Is that it?
Well, not exactly…. There are many smaller stages involved, such as code reviews and documentation, but for the most part this is it! We hope this brief overview will give you a good idea of how feature development work happens in Habbo!
comunque usate google traduttore
interessante