|
So let me introduce myself as everybody before me did. My name is Ivan and I’ve been working as a software tester on the Bumblehood project for almost a year and a half. In my first post I will tell you something about challenges of software testing. But befor that, let me briefly describe my work here in Bumblehood.
The initial phase of the software testing process is not - as everyone outside IT automatically assumes - to open the application and start clicking everywhere until the application stops responding. The first step is getting to know and understand the project documentation which mostly includes feature requirements, GUI specifications and use cases. The next step is to write a good test case according to the specs. Only after writing a good test case - and putting it to a corresponding test suite, the “clicking job” can really begin.
Functional testing is my favorite part of the whole software testing process. Every new functionality is a new challenge and questions like “Can a user do this?” or “Does this new feature work as described?” are brought up on a regular basis here in Bumblehood. Of course, a lot of regression testing – the most boring type of testing – also has to be done, to ensure that no additional errors were introduced in the process of fixing other issues.
So what are the top challenges for a tester? There are quite a few challenges which every tester has to face and cope. Here are some of the most important ones in my opinion.
Deciding which tests to execute first is a very important challenge – what has the higher priority? Bug fix confirmation or a new feature? The answer is sometimes self-explanatory, but not all the questions are as easy as the previous one. So ability to work under pressure is essential for this challenge.
Regression testing is also a big challenge - as the project is expanding the pressure rises and it is difficult to handle constant functionality changes and in the mean time check previously working functionalites and bug tracking.
Proper understanding of exact requirements can also be a significant issue. Did a person who wrote the requirement miss something? What if I completely misunderstand the requirement? Therefore, a logical mind and a lot of team work are necessary to overcome this obstacle.
Relationship with developers is another delicate challenge for both testers and other developers, particularly because both parties can make a thousand excuses when they do not agree with some points. Good communication skills, troubleshooting and analyzing skills are essential for a good tester.
For the end of this post, here’s a picturesque joke about developer – tester relationship.
Posted by Ivan Lajtman on May 10th 2010 --- Permalink --- Tagged in categories: Software team --- Comments on Forum
|
Hi there! Since this is my first contribution to this blog, I'll shortly introduce myself.My name is Miroslav, better known to all as Kela. I've been a Bumblebee for almost two years and I’m currently working on this project as a senior software architect. My previous work experience is based on many different technologies and work methodologies.
A couple months ago we have started a parallel project, the BonusCard Program, in which I currently participate. So I'll tell you a little bit about it.
There are many customer loyalty programs on the market, and many of them are quite successful. Most of them are using very simple business models, which ensures customer satisfaction and ultimately gaining a higher profit to the company. The business model is not designed only to satisfy the current customer but to get new ones as well. In general that includes business models which have changed in time and are dependent on the current market situation. Loyalty programs are mostly driven by market analysis and marketing plans (loyalty marketing).
There are many concepts and models; some of them are using cycle of success and cycle of failure concepts. However, general investment in employees, their correct selection and training will create a corporate culture in which they are empowered, and that can lead to increased employee satisfaction and motivation. Such concepts will, in turn, likely result in better service delivery and more likely in better customer satisfaction. Customer loyalty will be increased as a result, improving sales levels and gaining higher profit margins. One of key elements to evaluate customer satisfaction and loyalty is through customer's feedback to a particular business.
Loyalty programs are marketing efforts that encourage and reward customers’ buying behavior. Customers are provided with loyalty cards, rewards cards, club cards or point cards which can be made out of paper or plastic. Those cards are usually identical in size to credit or debit cards, or even smaller, and they identify the cardholder as a member of a particular loyalty program.
Loyalty cards are mostly used by customers to gain discounts or to collect points that can be used for future services. In most cases, the card issuer requires the potential cardholder to provide a (most often) minimal amount of identifying data, such as name and address. Application forms usually entail agreements concerning customer privacy. Aggregate data is most often used internally (sometimes even externally) as a part of market research.
Those were some general facts about loyalty programs in general. Stay tuned for subsequent posts!
Posted by Miroslav Kelekovic on January 7th, 2010 --- Permalink --- Tagged in categories: Software Team --- Comments on Forum
Since all my colleagues before me started their first blog post with an introduction I will do the same. My name is Goran Hacek and I am one of the developers here at Bumblehood.
Today I would like to share the results of one of my side projects with you. As the size of the Bumblehood content database has grown significantly, a need for tools that provide insight into the state of that content arose. One of the tools that I have been working on is for visualizing link states in local guides - today we are making this tool publicly available. You can access it by following this link.
The tool collects data about internal topic linking and visualizes that data in an informative and at the same time visually appealing way. Local guides are displayed as radial trees of topics. In the center of an image is the root of a tree, and all nodes in particular depth are placed on a circle with the same radius; as the node depth grows so does the circle radius.
Topics are displayed as circles. Their interior radius represents the number of outgoing links from that topic while its border width represents the number of incoming links (number of Bumblehood internal links that are pointing to that topic). Labels are displayed only for leafs of a topic guide and their size is calculated by taking both the number of outgoing and incoming links into account.
We have a couple more ideas about what to visualize and in which way (I will write more about this in the following posts), but if you have any ideas of your own about what could be interesting for you to see please don’t hesitate to write on our forums. Also, tell us your opinions about these visualizations.
Posted by Goran Hacek on August 31st, 2009 --- Permalink --- Tagged in categories: Software team --- Comments on Forum
|
There are several blog entries made by members of Software Team at Bumblehood, but none of them is mine. So to make things right, the first part of this post will be a short introduction with a little bit of history. My name is Marko, and I'm currently finishing studies at the Faculty of Electrical Engineering and Computer Science (FER) at the University of Zagreb, with 3 exams left at the time of writing. Along with my studies, I have been working here at Bumblehood for about a year and a half as a college intern. A lot of things happened in that period. Bumblehood and Bumblemap projects developed from early system drafts made on blackboard in the office in Munich, to fully developed scalable application. This required a lot of work and effort, sometimes staying up all night making deployments and testing before the deadlines, but also we had some fun times while working.
For this first post I will write about experience gathered by working in the Software Team in Bumblehood and what are the highest priorities in making new features and releases. Bumblehood project encompasses many successful and proven tools for Java and Javascript development. Its backbone is the modular Spring Framework which is a top tool for building modern, scalable and extensive enterprise applications (replacement for bloated J2EE application servers). Most of the tools are open-source and they made our life a little bit easier. But relying only on good tools is not all. Far from it.
If you ask an average developer how long does it take to develop a wiki community portal software, he will probably say something like this: "I can make it in one weekend, and a high school student would do it in 2 weeks. It's trivial." In his eyes Bumblehood would be nothing more than an "Edit" button and "Submit" button. When you press "Submit", text is stored in database in some table and it's retrieved when you press a button on your mouse on the topic link. There is a tremendous amount of polish added to rough core system here at Bumblehood project. I know because I see the code every day :). A vast majority of users which are using Bumblehood agree that the overall user experience from start to finish is enjoyable. Ultimately, user experience is the only thing that counts. It's also a very complicated and abstract term. It goes far beyond a of list of features and sources of information, and consists of simple, clean and responsive user interface, page loading speed, page flow and much more. If users find what they need quickly without much fuss, that is also helpful. And the most important thing is that improving user experience is an iterative process. So every day one busy Bumblebee in the Software Team (and in other teams too :)) has only one goal in mind, and that is not making the best Bumblehood code ever, but making the best Bumblehood experience ever.
This was a short insight in Bumblehood software policy, I hope you liked the post! You can send me a message on my public wall whenever you need my help on Bumblehood, or if you just want to say hi!
PS. I didn’t make up this talk between 2 developers about triviality of developing software. I accidentally overheard this talk between two guys during lunch time in our team’s unofficial diner - Modena. :)
Posted by Marko Mrkus on July 30th, 2009 --- Permalink --- Tagged in categories: Software team --- Comments on Forum
|
When IE6 was launched some time in 2001, I was just a college freshman with a big interest in the Internet, a small interest in how websites work and no interest whatsoever in browsers, standards and all the other stuff that defined how things work the way they did (or at least should). As almost every boy over the course of his childhood tries to disassemble a toy to see what makes the wheels on a toy car spin, I was certainly no exception. But in my case this exploring spirt hasn't faded out yet. That's how HTML and I first met :)
After I constructed several „Hello world“ dummies, I think it was in 2003 that I launched my first real web site. The site looked fairly cool, at least from my perspective and for my level of expertise at that time. There was a whole lot of DHTML which was a big buzz back then... However, the most important thing was – it worked. At least I thought so, since I had no reason to believe otherwise. Back then I had no idea that anything other than IE5.5+ existed (anything important, that is). And even if it existed, I thought in my blessed ignorance, how different can a web page look in another browser? You've seen one, you've seen them all... The only difference is in the company that makes it and maybe GUI skin. Yeah, right... Until one day I saw my site in Netscape Navigator. The horror I saw that day is still haunting me from time to time... Javascript errors, hidden menus jumping all over the place... Horrible.
My experience back then is probably how many client-side developers feel today after testing their web apps in IE6, the very same ones they've just completed to be W3C compliant and work flawlessly in standards-compliant browsers. However, NN was at that time a tired old browser at the sunset of it's existence, and today IE6 is a big boring yet vigorous old hag that just keeps annoying you day and day again.
Due to its lack of support for advanced CSS and XHTML, IE6 can be considered to be really holding back the web. With so many alternatives available, and after the release of Internet Explorer 8 which put IE in the standards-compliancy era, it's time to take the web to the next step.
Four months after our launch, although IE6 usage on Bumblehood is still not low enough to be considered irrelevant, what's encouraging is the fact that both IE general share and IE6 share are dropping constantly at a pace greater than 0.5% on amonthly basis. This pace is a good signal, given the fact that IE6 already dropped significantly in 2007/2008 and that the last few pounds are the hardest to lose. What's discouraging enough is the fact that at this pace, it would take almost two more years for IE6 to drop to levels where it could no longer be considered worth supporting. That means two more years of excessive development needed to enable your web-apps for the uninformed minority. Two more years... Probably even Microsoft itself will abandon any kind of support for IE6.
A decision to stop supporting almost a fifth of the audience (IE6 market share accounts up to 16.94% in May 2009 according to NetApplications) is something designers and developers are not quite comfortable with. Yet this decision has to be made, whether several weeks of lower traffic (and consequentially a lower income) are a small sacrifice for a greater goal of getting the Internet out of the stone age. Having in mind that Pareto's principle can also be recognized in tweaks and hacks required for sites to work in IE6, it's not that hard to calculate what limited support for IE6 can contribute to extra development time.
When decomposed to a logical level, it is really easy – people are using IE6 and aren't considering replacing it with more up-to-date browsers simply due to the fact that „everything works“ in IE6. If „everything works“, it can't be that bad after all, so why bother changing it. As long as the websites are tweaked and hacked to work in IE6, people will use it to visit websites. Once the people are unable to use the majority of web services with IE6, its usage will be abandoned. What one in client-side development can do is inform the visitor that his experience of the website could improve significantly with a modern browser (or even going maybe a bit down the extreme road and letting people know that the web cannot be viewed in IE6), people will consider alternatives. Just imagine if Google, Gmail and FaceBook decided that IE6 is no longer supported by their apps - would that be a large enough impulse for the significant part of IE6 users to switch to alternative browsers?
What about us? As much as I'd like to completely abandon support for IE6, I'm quite sure the management will disagree with this idea, as it means 15% lower traffic. 15% for a start-up is worth pure gold, I know. Since Bumblehood already supports IE6 in read-mode beta, there's no point in changing this approach overnight. But with launch-day approaching for edit-mode beta and IE6 being unsupported in the first iteration, I sincerely hope that our stand towards IE6 will not change significantly more than providing limited support for content editing in IE6. That's the least we can do for the web.
Posted by Dino Ursic on June 30th, 2009 --- Permalink --- Tagged in categories: Software team --- Comments on Forum
|
The World Wide Web in its today’s form brings significant benefits to web users by allowing them to perform a simple keyword-based search against hyper-textual information stored in tens of billions of web pages in a matter of second. The keyword-based search as the only search mechanism, however, severely limits the possibility of finding wanted information. Firstly, the search mechanism based purely on matching text strings does not take into account the underlying meaning of information, and secondly, the absence of implied semantic relationship makes organizing the relevant search results and presenting them systematically hard if not impossible.
Semantic web, pioneered as a layer on top of the classic web that adds semantic metadata to information enable computers to process and understand data in an intelligible way. This makes them (at least theoretically) able to perform more complex tasks regarding information finding and to obtain better end search results. To underpin semantic meaning, such approach also advocates use of ontologies, formal representations of a set of concepts within a knowledge domain and the relationships between those concepts.
Both ontology modeling and metadata creation can be seen as major obstacles to a wider adoption of semantic web. Ontology modeling, unfortunately, cannot be avoided; however, it is ideally to be performed by a small number of domain experts proficient in the underlying technological solution. On the other hand, manual annotation of documents with metadata is unlikely to be appreciated by knowledge contributors, unless the system provides support for reducing such workload (e.g. in the form of relieving a user of explicitly entering automatically deducible annotations).
Several enabling technologies have emerged as a part of the global semantic web effort. Arguably the most widely used one is the Resource Description Framework (RDF), a language for representing information about web resources. RDF, together with RDF Schema (RDFS) and the Web Ontology Language (OWL) constitutes the W3C cornerstone for formal description of concepts, terms, and relationships within a particular knowledge domain. The format of RDF expressions follows the subject-predicate-object form (known as RDF triple), e.g., the sentence “James T. Kirk commanded USS Enterprise” could be represented as (JamesTKirk, commanded, UssEnterprise). There is a number of RDF serialization formats (such as RDF XML serialization or RDFa) that can be used to semantically annotate hypertext data with and embed such annotations in web pages.
Topic Maps also emerged as a form of semantic web technology. While Topic Maps and RDF are very much aligned, they seem to be intended for different purposes (which stems from the original context they were developed in). As explained in detail in this article, while RDF was developed to support the semantic web vision by providing structured metadata about information and a foundation for logically inferring new information based on the explicitly provided data, Topic Maps were created to support high-level indexing of sets of information resources to make the information in them findable.
The key trait of Topic Maps that makes them particularly suitable for a web application like Bumblehood is that they can be envisioned as a hidden assistance provider to community-driven process of contributing information. Namely, Topic Maps take a topic-centric view of the information space, while RDF takes a resource-centric view. In my opinion, people are more likely to grasp on semantic annotations pertaining to topics than to particular resources. Furthermore, RDF as a language is more of a “lower-level” one with few semantics of its own, whereas Topic Maps are a "higher-level" language with relatively rich semantics. To be more precise, Topic Maps actually do not operate at the syntax level per se, but they are a paradigm. One does not need to stick to a particular data model for Topic Maps (as long as it conforms to the Topic Maps reference model), and can make the implementation by using any technology.
Alongside technological implications lies yet another, and probably the most important one – the approach, no matter whether RDF or Topic Maps, must be made to work for the benefit of its users. Both RDF and Topic Maps are a powerful way of organizing information, however, for working with complex structures, effective user interface is of uttermost importance. Successful implementation of a semantic web based system should require from a user to enter as few semantic annotations as possible, while enhancing user's perception of relevant information and providing facilities for easy navigation. In Bumblehood, we saw Topic Maps as particularly adequate for driving the latter, which we materialized through our tree-based visualization.
In conclusion, although one could argue that RDF and Topic Maps are equivalent on a theoretical level, and that one could be used in place of another, I hope that with arguments in this blog post I provided a sound explanation as to why we believe Topic Maps were the natural choice for Bumblehood.
Posted by Matko Botincan on May 22nd, 2009 --- Permalink --- Tagged in categories: Software team --- Comments on Forum
|
Topic Maps are an ISO standard for organizing knowledge structures and associating them with information resources. Originally initiated outside the semantic web context and evolved from efforts to develop electronic indexes, they emphasize the ability for locating information within a large pool of information resources. As such, they are particularly suited for tasks involving discovery and navigation of knowledge bases, and thus constitute a promising enabling technology not only for semantic web, but for knowledge management in general.
A topic map consists of a set of topics capturing subjects from some knowledge domain and maps them to resources referring to information about the subjects. A topic in a topic map can stand for literally any entity (e.g. a person, an event, a business entity, an abstract concept, etc.) regardless of the entity’s specific characteristics. The subject a topic speaks about is given by topic’s name, and a topic can also be assigned a type. Relationships between topics are expressed by topic associations which put into a relationship any number of topics. Like topics, associations can also be categorized according to their types, and each topic participating in an association has a clearly identified role. Information resources a topic is linked to are called occurrences of the topic. These three concepts – topics, associations and occurrences – constitute the Topic Maps key ingredients – the TAO of Topic Maps.
In order to exemplify these concepts, let us have a short look at the topic map in Bumblehood. For example, London is a topic that speaks about the subject London, the capital of the United Kingdom (N.B. to be precise about the subject, we need to disambiguate from other meanings of London). Its topic type is “city” and it appears in the article about London shown in the right pane. It is in a parent-child association with the topic Cities of the United Kingdom where it plays the role of a child, and in associations of the same type with topics Local guide to London, Areas in London and Local businesses of London where it plays the role of a parent.
However, there is much more in Topic Maps than just separating relationships between topics from their occurrences in resources. We see on the London example how important it is to have knowledge of the identity of the topic’s subject, so that when referring to “London” we know that we are not referring to London in Queensland, London in Kentucky or London the writer. Furthermore, the topic map ontology developed for a particular application has to be supported with a mechanism for defining constraints on the topic map that will enforce the assumed semantic rules. For instance, in Bumblehood’s geographical ontology, only topics of certain types are allowed to be put into an association – only a city can be placed in a city container, while either a city or a country region can be put in a country’s regions container. On the other hand, it does not make sense to have a country container underneath a city. You can also see that Local guide appears as a child topic only for topics of certain types, and the semantic rules for local businesses are even more complex.
A large body of work has been done in regard to Topic Maps, however, techniques that support dealing with complex constraints still seem to be in their early beginnings. Arguably the most prominent approach is the Topic Map Constraint Language, a formal language for defining schemas and constraints on topic map models defined by the Data Model for Topic Maps. We did not follow this route in BumbleMap, but we implemented an approach of our own that allows us to specify the semantic rules we need in Bumblehood more easily. It is the subject of future work to see whether this approach could be exposed as a fully fledged language like TMCL, however, we believe that even in its current form it offers a beneficial solution.
Posted by Matko Botincan on May 15th, 2009 --- Permalink --- Tagged in categories: Software team --- Comments on Forum
|
As some bumblebees already know, Bumblehood portal is powered by BumbleMap, a software platform for collaborative knowledge management. The introductory article about BumbleMap platform portrays its key features and pinpoints utilization of the topic maps paradigm as one of its bedrocks. Topic maps are a form of semantic web technology for knowledge representation, and in this blog post, I would like to explain a bit why we chose to employ them in BumbleMap. Also, I will try to give my perspective on how Bumblehood fits the semantic web area in general.
The key idea behind semantic web is adding a well-defined meaning to information on the web (typically in the form of semantic annotations) in order to provide more powerful searching capabilities and allow better processing and understanding of data. These characteristics, at least in theory, bring benefits to both kinds of web users – people and machines – making development in the area of semantic web even more appealing. Although 8 years have already passed since the term semantic web first appeared in public (in a Scientific American article), its repercussions among web users, however, are disputable at best. The fact that the web world has not been turned inside out as some might have expected is hardly unanticipated, but it comes as a bit of a surprise that even 8 years later no “mainstream” semantic web application seems to be successfully solving a problem of general public’s interest.
When the Bumblehood project started, the possible benefits it could have from semantic web technologies, and, in particular, the topic maps paradigm, were not evident at first. Only when problems pertaining to consistent organization and presentation of Bumblehood content about geographical locations and businesses arose, the topic maps paradigm came out as a natural path to follow. I find this worth mentioning because I believe that one of the reasons for the public perception that not much progress has been made in the semantic web area is a lack of well-motivated applications dealing with problems that people care about and for which the semantic web technology can provide a good solution. I am even under impression that many applications that emerged around the semantic web hype suffer from clear identification of the goals they are supposed to achieve. And even those that are clear about the goals have hard times bringing the underlying solution to their users without sacrificing usability of the application and the overall user experience (e.g., see the story of Twine).
Back to Bumblehood, the topic maps paradigm helped us not only to overcome the difficulties with information organization, but it also opened us a way for presenting Bumblehood content in a structured form that is easy to navigate. The approach you now see in Bumblehood is the one we found the most appropriate for the kind of semantic relationships among information entities that are present in the Bumblehood content. One might argue that the tree-based visualization of Bumblehood topics is utterly simple and does not appear as the most general approach one could come up with in order to lay out arbitrary semantic structures (e.g. check this project providing an API for visualizing graph and tree structures in a hyperbolic geometry). We are not trying to dispute such efforts, however, we firmly believe that it is wisest to keep things simple (of course, not simpler than that:) and use only what is necessary in order to defeat the problem. Only time will tell whether a tree-based visualization could be the right approach for “mainstream” semantic web applications in general, but even if it does not turn out to be so, we are convinced that we made the right choice for Bumblehood by using it.
Keeping in mind that “best things come in small packages”, I conclude this blog post, and announce its next part in which I will delve more into the role of topic maps in Bumblehood and dissect how this paradigm is applied in the domain of Bumblehood content.
Posted by Matko Botincan on May 6th, 2009 --- Permalink --- Tagged in categories: Software team --- Comments on Forum
|
I joined the project in March 2006, after having previously worked for small to medium scale companies doing web applications for banks and other clients in Munich. When Boro presented to me the idea of a community-driven feedback system, I was thrilled, so we started working for our own company. Nothing could have stopped us and it was a very enthusiastic period of time. We had a lot of work, but we were the ones who were defining the goals, planning the tasks and doing them one by one. A completely different atmosphere from having someone else tell you what to do. Such shift was actually not easy for me :)
Having set up the office, bought and installed computers, and created infrastructure for Munich-Zagreb collaboration with two more developers, we started our work on software. We used what we knew best, namely web design and java. For me, this was also an opportunity to apply domain-driven design, which connected our ideas to the software we were creating. This approach helps you focus on the domain, on finding problem-solving models, rather than just on technologies. Having a chance to set up everything from scratch was a valuable experience to us.
At that time we were defining the first specifications of the software, in an informal way and with help of basic questions like:
• "What do we have to do?"
• "Ok, but how exactly will this work?"
• "I haven't seen anything like this before, will it be accepted?"
Sometimes answers were clear to some of us, but most of the time they weren't and it felt like blind walking. We moved slowly, starting with the navigation tree. While Vrc and Dino did the GUI prototype, I focused on the infrastructure and backend. At that time, Boro defined most of project requirements.
I communicated with Dino and Vrc over voip phones and IMs. With voip phones and RealVNC, we were able to establish a kind of tele-presence by sharing a desktop and doing pair programming.
Among the most interesting project activities were week-long brainstorming meetings, when most of team members gathered either in Munich or Zagreb and had day-long talks about solutions to problems. During that time, we went out at least once a week, to a beer hall or to the famous Oktoberfest in Munich, and to some traditional restaurants like Medvedgrad in Zagreb.
18 months ago, after having developed the first prototype and enlarged our team, we discovered Topic Maps paradigm, which fitted in our project perfectly and gave us more insight into what we wanted to do. This was just an addition to the current software, but the infrastructure remained the same, comprised of many software technologies chosen from open source space, such as Tapestry, StringTemplate, Spring, Hibernate, MySQL, Lucene, dojo, TinyMCE, Ant, Maven, TestNG, Tomcat, Apache HTTP Server and others.
All of them are integrated in BumbleMap product and all of them offer a one-stop-shop solution which, with time, was either extended, changed or simply replaced. None of these actions would have been possible if we hadn't learned from the open technologies and their backend communities.
Also, our families and friends contributed to the project with their patience and support... I know my girls, Vilte and Daina, experienced my absence most. I am grateful for your support, girls, thank you.
Posted by Claudiu Dobre on April 6th, 2009 --- Permalink --- Tagged in categories: Software team --- Comments on Forum
|
As this is the first post from our sysadmin team, it would be nice to get to know each other. I'm Davor, people call me Horza and I'm in charge of system administration for Bumblehood. This blog will be about the stuff that happens in our project from the system administration point of view. Now since my colleagues, Gabi, Boro and Sasa mostly ranted about our problems in their previous posts, I'll try to stick to nicer, shiny-happy topics and hopefully give some insight into our server architecture and some of the solutions that we employed to power it all up.
Oh, and just to give you a bit of warning - there will be some tech gibberish here from time to time. But not in this one, this one is about people from all departments who work to bring Bumblehood to life.
During a year or so that I'm with the company, we have been thinking hard about the architecture that is required to bring users a pleasant surfing experience and explore Bumblehood using the powerful BumbleMap platform our software team developed. And like in every other project, there was (is?) a constant "battle" between our software guys and server gnomes ending usually in both sides making a compromise. Of course this wasn't a real conflict; more like a project-wide cooperation to determine if some feature should take many resources from our servers, or should it be rewritten to take less. This clash of two worlds happens not only between devel and sysadmin guys, but also between devel and content departments, and between content and sysadmin as well. I won't even start about different views that the nice folks in charge of business development have compared to us techies and writers. But despite difference in our views, one thing that we all had in mind all of this time was to have a product that users will like when the D-day comes. So we all joined together and worked to finish all the work on time.
But, besides our work on the project itself, there were also two interesting side-effects that are perhaps more important than the work we are doing here. Those things are about us as people and coworkers.
The first noticeable side-effect that goes on in Bumblehood is that we are learning from each other. But not the standard way, you know those regular work-related things that you learn at any other company at some regular pace. This experience is a little bit different. Since there is so much diversity between different departments here, we are bombarded with new things on daily basis. I'm not talking about work related facts or knowledge, but about the stuff that we didn't know existed, and from areas we would have probably never learned ourselves.
For example, a couple of days ago, I was chatting with a colleague from our content editing team about what to cook that evening, so she mentioned something about Mexican food. And a couple of hours later, I somehow found myself reading about Main industries in Mexico. :) That was a really weird experience, that came to me like an epiphany, because I would really never have read it if she hadn't mentioned something interesting about the Mexican cuisine. And through that I've learned some new things that I never thought about. Of course, I've learned a lot more from our development team, but that's mostly related to technology, so it's a bit pointless to talk about all that stuff.
The cool thing about working with different people here is that we have a great opportunity to learn not only about work, but also a lot about all sorts of topics from the "common knowledge", and all that while performing our everyday job. And you can imagine how much that influences the level of motivation.
The second interesting side-effect I wanted to talk about is happening in human relations. It's quite normal for people who work together to get to know each other better every day. But here at Bumblehood we have been through some tough times together, and we have been working as one to push this project as well as we can. That caused quite a bit of stress and really put us all to a test, not only as coworkers, but also as people. And I think we can all say that we passed it with flying colors. Even when the things got quite tough, there were no nervous breakdowns, no shouting (ok, almost no shouting :) ), and significantly less tension than one would expect from a team this big that had been working 10 to 16 hours a day for a longer period of time. And we still had enough in us to grab a beer after work. Anyhow, we all stuck together and went through it all as professionals, and during that time we really found out a lot of our human and not just business side.
Right now, couple of months after the big stressful period has begun I think we can say that we have all made some friends here, not just established excellent working relationship. It will be interesting to see how it will develop now when one rough patch is behind us and another one approaching.
I would like to conclude this introductory post by saying thanks to everyone who made this project what it is now and for being a great team.
Posted by Davor Grubisa on March 23, 2009 --- Permalink --- Tagged in categories: Software team --- Comments on Forum
|
After months of continuous brainstorming, designing, implementing and refactoring, the D day (D stands for deployment, what else could it be :)) finally arrived. The day started at 9am with the last conference team meeting before the deployment. The plan was to add a finishing touch to Bumblehood application and to start with the deployment. Although it was Monday, the beginning of the week, the spirits were high, both in Munich and Zagreb office. You could see the excitement on the faces of team members. Maybe snacks and refreshing drinks contributed to general atmosphere in the office... or maybe everybody just wanted to get this thing over with and take it off the agenda :)
The first part of the plan (adding that final touch) was done as expected - on time and without any problems worth mentioning. Good, first task completed...
I was aware that the second part, deployment (on test servers and on production servers, respectively) might not (and probably would not) go so smoothly. After all, I had several big D days in my professional career and I know from experience that our good "friend" Murphy is always here, waiting behind the corner to surprise you, unannounced and when you least expect him.
And Mr. M. showed up sooner than expected. The deployment on test server failed – the application wouldn't start. How come??? The deployment on test servers had been successfully done several times over the last few days. Uh, we hadn’t even reached the production environment and we already had problems (and I’ve got one more grey hair). A thorough check was immediately done. Luckily, we found both the cause of and the solution to the problem very fast. After some testing conducted by all team members, the conclusion was that the test environment was up and running. One more task completed...
Production servers were prepared and there was just one, though big, step to take. Before we started, I looked at my watch and I was really surprised. It was already evening - I didn't even notice there was no more sunlight outside. The deployment on production servers started without any obvious problems – several minutes of waiting and voila – it failed again :(( Ok, I said to myself, we had the same problem with testing environments and we'll fix it in no time. But, Murphy says, no, no. It was time to drink the refreshing drinks we had and go through the checklist:
According to the checklist, everything should have been working... but it didn’t.
Ok, restart and go over again. I thought, if we restart servers and go through the checklist enough times, the application would start running at some point :))
Each team member checked his parts (code, configuration...). The atmosphere in the office was not so relaxed any more. The phone line with Munich office was open, so we tried to solve the problem by attacking it from north and south. Questions like "What is wrong?", "How much more time do you need?", "When we'll be live?" did not contribute to improving the atmosphere and were mostly ignored and unanswered. The problem was detected after some time and we immediately started to work on the solution. It was already long after midnight. It was still 16th of February in North and South America, so technically, we didn't miss our deadline (since our targeted audience is from all over the world :))). This work on the solution didn't include all team members, but nobody was unreachable - they were either in the office or online (on ICQ). After working on the solution with Claudiu from the Munich office for some time, I had to stand up to stretch my legs a bit. And what did I see?
When everything was fixed and finally deployed on the production environment, I asked the team members to test the application. My request came with a raised voice. Dino woke up, put his hands on the keyboard and started to press keys without any order, as if already testing for some time. At that point, we all burst out laughing.
Having passed the final test - we were live. Tired, but very proud to have developed something what we can present to the internet society.
Tuesday was a working day, but we worked the 2nd shift.
Posted by Sasa Saric on March 06, 2009 --- Permalink --- Tagged in categories: Software team --- Comments on Forum
