Disadvantages of working with remote teams and how to fix them
A common situation in the modern world is when clients are located in a different city, country or even continent. With ever increasing globalization the remote cooperation model becomes more and more popular, though it has own positive and negative sides. While positive sides are obvious, there must be a way to avoid the negative impact.
Let us investigate the major disadvantages of working with a remote software development team and ways of solving them.
Controlling a remote team
When a team is working remotely, it is hard to evaluate how effectively people do their job (and whether they are doing it at all) or why they don’t respond quickly enough. That suspicion can easily grow into distrust and uncomfortable communication with the team.
Of course you can handle this by installing the software that allows you to see people’s screens or by requiring to send reports every day, or by controlling them in some other even more sophisticated ways. But what actually turns a remote group of people into a team comfortable to work with, is the way they (not you!) handle such problem.
Usually every project has it’s own milestones. So when the product gets some visible functionality that can be presented to and tested by the client, delivering such results according to the plan agreed with the client is a great way to showcase team efficiency, keep the communication positive and build relations.
In RubyGarage, when the product is already designed and it’s time to set the scope (tasks, goals, deliverables, deadlines and cost), the team’s project manager additionally defines how to make you stay aware of what is going on. We believe that a great leader should always worry about how to communicate properly with the client, bring constant feedback and show achievements of the team.
■
The sharing economy has been growing rapidly, leading many people to consider starting their own online marketplace. Web-based marketplaces can help people share goods, services, accommodations, and relevant information.
If you want to develop your own online marketplace, you first need to know roughly how much a marketplace will cost.
There are essentially two options for developing a marketplace. You can develop on a platform, such as Sharetribe (built with the Ruby on Rails framework), that offers certain ready-made solutions. Using Sharetribe or a similar platform is the fastest and cheapest way to develop a marketplace.
The second option is to build a marketplace from scratch. Although this option demands more time and money, a bespoke marketplace can be customized to meet your specific needs better than a platform such as Sharetribe.
We can help you decide which option is right for you during the requirements elicitation stage.
From the technical point of view, creating an online marketplace is easy for us for a few reasons:
- We have experience building marketplaces
- We have our own libraries that we use in marketplace projects
- We use Sharetribe, which is a great open source solution that speeds up marketplace development
We’re going to provide you with two estimates: the cost of building a web marketplace from scratch and the cost of building a web marketplace using Sharetribe.
Technology Stack for Building a Marketplace
The technology stack we use to build marketplaces varies depending on a marketplace’s specifications. But we typically use the technologies listed below:
- Sharetribe
- HAML
- Sass
- CoffeeScript
- Ruby
- Ruby on Rails
- RSpec
- Capybara
- PostgreSQL
Keep in mind that we listed only core frameworks and preprocessors, and the stack usually includes more technologies. The technology stack may also change should we consider other frontend frameworks.
How We Estimate a Marketplace Project
According to Agile principles, we estimate development tasks in story points rather than in hours (you can read more about reasons to estimate with story points). But for the purposes of this article we’ll provide you with a story points estimation converted into an hourly rate estimation.
Implementing a marketplace, regardless of whether the marketplace is based on Sharetribe or made from scratch, is similar to implementing any other web application. Here’s the work we’ll do, in a general sense:
- User Interface and User Experience design (the look & feel and behavior of the marketplace)
- Responsive HTML and CSS (so your marketplace works great on any device)
- Front-end programming (user interactions in the browser)
- Back-end programming (server-side business logic)
- Automation tests to remove bugs
- Acceptance tests (manual testing)
After the initial launch of a marketplace we collect feedback from users, and after that we’ll need to develop your marketplace further. In the next section, we’ll provide you with our estimates for marketplace development, both made with Sharetribe and built from scratch.
How Much Will Your Marketplace MVP Cost?
Building a marketplace Minimum Viable Product (MVP) with common features is a practical first step, as you’ll be able to launch your marketplace as soon as possible. The faster a marketplace is released, the faster we can figure out what to improve.
In the article you’ll find a detailed explanation, expressed in user stories, of the functionality that will be included in your marketplace MVP. We’ll also provide an estimate in story points for each feature.
According to our estimation, a marketplace MVP requires 87 Story Points. 87 Story Points translate to around 750 hours of development time if a marketplace is built on Sharetribe, and around 1050 hours if we develop your project without Sharetribe.
We analyzed data provided by Clutch.co to show an average hourly rate for web development teams in several countries. Here’s what the hourly rates looks like:
About Open Source Software Security
Security concerns are the main reason why most companies and startups are hesitant to use open source software (OSS) in their projects. When part of a project’s code is open, it seems vulnerable to security threats and more likely to be copied. In this article we’re going to debunk some common myths about the security of open source solutions.
1. Anyone can read open code and take advantage of bugs
While open source code can be read and compromised in principle, in practice the situation is much more complicated.
First, according to expert opinion, people who break software don’t actually need to look at the source code. For an experienced developer there’s no need to dig into thousands of lines of code to find a vulnerable piece. So why do people claim that open source code is insecure?
In reality, any kind of code (closed source or open source) brings security threats to a product. Ultimately, it’s developers who make open source code secure or insecure; insecurities arise due to a number of mistakes such as:
- not following security guidelines
- improperly setting up software
- using easy passwords
- lack of data validation processes
- absence of data encryption techniques
The second reason why the situation is more complicated in practice is because the fact that anyone can read code actually increases your chances of finding and fixing bugs. Open source projects, as a rule, have vibrant communities that continuously support them and check them for flaws. Also, developers care about their reputations, and want to show off code that’s written in accordance with best practices and want to find and fix potential security vulnerabilities.
2. No financial incentive means no motivation to make OSS secure
Actually, many successful open source products have become profitable for the teams behind them. For instance, Mozilla gets a significant part of the revenue from Firefox for user click-throughs on search page ads. Most projects of this caliber have their own security response teams dedicated to patching vulnerabilities.
In the case of open source tools that aren’t profitable, when a vulnerability is found, the open source project team will usually either immediately fix it (since their reputation is at stake), or disclose the issue publicly so that all those implementing the code can take appropriate measures — for example, switching off the vulnerable functionality or setting other hardware and software to avoid using the affected functionality until it’s fixed.
As far as the motivation to develop open source software is concerned, each individual developer in the OSS community is motivated to offer a high-quality product with no major flaws in order to prove their own competence. On the other hand, businesses are often limited in many ways (money, time, business objectives, etc.), and thus may actually limit the amounts they invest in product security. Because open source developers are personally motivated to work on the projects they select, the result is a thorough development process with fewer vulnerabilities in public releases.
Originally published here
How Junior Developers Can Contribute to Open Source Projects
It's never been easy to learn programming. But despite tons of ways to learn how to code, we believe that the best way to improve your skills is by contributing to open source projects.
The open source community provides a great opportunity for aspiring programmers to distinguish themselves; and by contributing to open source ruby projects, developers can improve their skills and get inspiration and support from like-minded people. But most importantly, they can prove that they can build fantastic experiences that people love.
Previously, we have discussed why open source is good for your business . In this article, we'll explain why you should contribute to open source projects, how to contribute, and what projects to choose. This article is geared towards developers who are just starting their career and would like to get involved with the open source community (and maybe become a coding genius).
Why contribute to open source projects?
There are a number of reasons to contribute to open source projects. Let's see what motivates developers to contribute.
First, there are a lot of enthusiasts who simply believe that code should be open. They're idealists who want to make the world a better place, and it drives them to contribute code. The desire to share can be a powerful motivator.
Second, open source projects give you a great start. Beginners might start by fixing minor things, such as a bug in a library, sending a pull request, or even writing a piece of documentation. However, beginner developers can also learn to write so-called "clean code" – code that is readable and maintainable – while contributing to open source projects. When developers realize that their code is exposed to the world, it makes them focus on making that code easy to understand and support. Programmers stick to generally accepted rules within a team, which include norms for indents, descriptions of methods and classes, variable names, and following the don't-repeat-yourself rule. In a nutshell, when contributing to open source projects you're obliged to conform to the norms of a project.
Third, you get the chance to be part of an active open source community where you can meet like-minded people and supporters. Moreover, if you're a freelancer and actively contribute to open source projects, you increase your chances of being noticed by potential employers.
The main reasons why developers go open source are to be recognized, to sharpen their programming skills, and to become part of the vibrant open source community. Now let's look at what you should consider before you start contributing.
What to consider before you go open source
Okay, so you can't wait to start your first open source project. Let's go through a few tips that might help you choose what to work on.
Programming language
The most fundamental technology behind any application is a programming language. The most popular languages on GitHub (a collaborative code hosting platform) are JavaScript, Python, Java, Ruby, and PHP. There are a multitude of projects that might suit your skills and taste.
Type of project
After you've chosen the language you want to work in, you need to choose the type of project you prefer. Github projects are categorized into folders called Showcases. Here are some examples of Showcases: "security", "virtual reality", "text editors", and "CSS preprocessors." Just choose a topic that interests you.
However, we do recommend paying extra attention to those projects that would be used by broad spectrum of people so you'll have the chance to test your code on a large real-world audience. For example, the "Emoji" Showcase contains 25 repositories that represent its popularity. Another tip on how to choose an open source project is to start working on software you already use or software you're interested in using. This will keep you motivated to keep on working.
Project volume
Large software projects like VLC Media Player or Spree – with thousands lines of code – aren't the best choice for a beginner. When you contribute to open source projects of this scale, you're expected to meet the established requirements within that team. A here's another small tip: pay attention to issue labels. Some issues are labeled as "first-timers-only", "beginner", "easy", and so on. You can also find a list on Github with collections of projects that suit newcomers.
Consider these tips when choosing a project to contribute to. And always remember to choose software you're interested in and allocate time in advance.
Originally published here https://rubygarage.org/blog/how-contribute-to-open-source-projects
How to Interview Your Ruby on Rails Developer
We at RubyGarage want to share our knowledge about how to interview a Ruby on Rails developer. Since our main purpose is to sell great code, we require great coders. This article will come in handy for a Chief Technical Officer who needs to test a Ruby on Rails programmer but isn’t sure what questions to ask the Rails interviewee. Ruby on Rails developers may also be interested in these questions. This article is a guide for how to interview a Ruby on Rails developer.
We’re not going to include all the questions you could ask, as that would take more than one article. For example, we decided to omit questions about code idioms and cunning expressions in Ruby. Also, we don’t want to give away all the questions which we might ask during an interview with a Ruby on Rails developer. We don't want a Ruby on Rails developer to simply look for answers on the Internet, as our main purpose is to ensure that we check the developer's grasp of the language and framework. We merely want to see how a Ruby software engineer expounds his or her knowledge of the domain.
Now let's chalk out the structure of a Ruby on Rails interview. The article will be divided into several parts since we usually check separate domains of knowledge. Here is the structure we typically use:
- Ruby questions;
- Ruby on Rails questions;
- A pair programming task;
- A home task.
Now it’s time to start asking questions to your Ruby on Rails developer to find out what they know!
Ruby Questions to Test a Web Developer
Why do we ask Ruby-related questions to a Ruby on Rails developer? Because the Rails framework is written in Ruby. This means that when we write code for Ruby on Rails, we’re using Ruby. The main issue we encounter with Ruby on Rails programmers is actually that they don’t completely understand the basics – the programming language itself. We want to hire forward-thinking software engineers who will create high-quality code, and so we want to assess their Ruby competence.
Our Ruby questions usually concern the Object Oriented Programming paradigm and object oriented design patterns. Class hierarchies, encapsulation, inheritance, and polymorphism are key concepts that every Ruby on Rails web developer should know well. If a programmer correctly answers a list of questions similar to the ones below, then we move forward. If they can’t answer them satisfactorily, then the interview is already over.
- What is a class?
- What is the difference between a class and a module?
- What is an object?
- How would you declare and use a constructor in Ruby?
- How would you create getter and setter methods in Ruby?
- Describe the difference between class and instance variables?
- What are the three levels of method access control for classes and what do they signify?
- What does ‘self’ mean?
- Explain how (almost) everything is an object in Ruby.
- Explain what singleton methods are. What is Eigenclass in Ruby?
- Describe Ruby method lookup path.
- Describe available Ruby callbacks. How can we use them in practice?
- What is the difference between Proc and lambda?
The Second Series of Ruby Questions: Business Applications
Knowing the basics is not enough to work for RubyGarage or for any other serious web development company. A programmer should also be able to explain how to write code for business applications. Since Rack is a very popular interface that makes it possible to develop an application in Ruby, we ask specific questions about it to a Ruby on Rails developer. Here are four possible questions and challenges:
- What is Rack?
- Explain the Rack application interface.
- Write a simple Rack application.
- How does Rack middleware works?
The Third Series of Ruby Questions: Ruby Gems
Ruby is a very popular programming language and it has a huge community of developers who create numerous helpful libraries. We at RubyGarage love gems because they simplify and accelerate the work process. Third-party code helps us develop web applications quickly and smoothly.
In this part of the Ruby on Rails interview, we want to learn how a Ruby web developer perceives the basic structure of a gem library. A developer will use multiple gems when building applications on the job, which is why it’s important for us to see if the developer can read and comprehend code written by other programmers. The interviewee should also describe RubyGems, which is a special system to create, implement, and share gems.
We have built up a series of four questions about Ruby gems:
- What is RubyGems? How does it work?
- How can you build your own Ruby gem?
- Explain the structure of a Ruby gem.
- Can you give me some examples of your favorite gems besides Ruby on Rails?
Ruby on Rails Interview Questions
Now it's time to plunge into the world of the Rails framework. A qualified Ruby on Rails developer should be familiar with the Model-View-Controller approach to building applications. This series of Ruby on Rails interview questions is divided into three groups. First, we ask some general questions related to the Ruby on Rails framework. Second, we want to see what the developer knows about routing, controllers, and views – the main parts of any business application.
And finally, the ActiveRecord-related questions let us test how the Ruby on Rails developer understands the Model part of an application. In order to work efficiently, a developer should write as little configuration code as possible when making ActiveRecord models. We ask about the conventions used for implementing such logic as well.
3 Reasons to Estimate with Story Points
In our previous article about estimating with Story Points, we concluded that Story Points are a handy and efficient measurement technique for estimating the amount of effort a team needs to develop a particular feature. Now, we’d like to talk about why, here at RubyGarage, we prefer estimating in Story Points as opposed to man-hours.
Man-Hours: What Are They and Why Don’t They Work for Us?
Estimating in man-hours is one of the most widespread approaches for estimating team work. It relies on an estimate of the amount of work that can be completed by one person within one hour. While man-hours are easy to understand, there are a few big drawbacks to this technique:
- Some tasks are difficult to estimate precisely.
- If one developer estimates a project but another completes the task, the estimate becomes invalid. The time needed to complete a task will vary based on a developer’s level of experience.
- People generally underestimate obstacles they might face and consider only the best-case scenario.
The bottom line is that drawbacks of estimating in man-hours outweigh the advantages and bring value neither to RubyGarage nor to our clients. But there are multiple reasons why we like estimating in Story Points.
Why Story Points?
With man-hours, developers expect that they’ll log the exact number of hours estimated for the sprint. But that’s a double-edged sword. If they exceed the number of hours estimated for a sprint, then it suggests they’re a poor performer. But if they complete the sprint under the estimated number of hours, then it means that there was something wrong with the estimate.
Story Points offer three main advantages over man-hours:
1. No correlation with skills and experience of the estimator
As we already mentioned, a specialist who estimates a task isn’t always the one who implements it. Senior and Junior developers need different amounts of time to complete the same task. The only way to avoid all this is to make a developer who estimates a project also implement that project.
Story Points eliminate this problem. Story Points are a universal measurement across the whole team. The estimate doesn’t depend on who’s implementing the story. All team members, with different skill levels, can discuss the estimate together and come to a single conclusion.
The whole team can get a clear understanding of the story size and complexity. This is the main advantage of story points.
2. Velocity is Tracked
Another key to the power of Story Point estimation is velocity. Velocity is a powerful capacity planning method that demonstrates how much product backlog effort a software development team can successfully handle in one sprint. The goal of a team is to raise its velocity.
Team members discuss ways to achieve greater velocity during retrospectives after each sprint. The higher the team's velocity, the higher the team's capacity to perform a given task quicker and more efficiently.
But velocity is a relative value that can change during the course of the project. And here, we find the next advantage of estimating with Story Points – you will not need to re-estimate your project if velocity changes, whereas estimating in man-hours would require you to perform a recalculation.
Read rest of the article here
If You Have Doubts About Using Spree Commerce
Looking for a web platform to make your e-commerce project up and running or switching from your current solution to something more innovative and advanced? It’s a common case for our clients. But how should one make a final choice? So many questions, so many doubts. We have collected the most popular questions we receive from our customers to help you make that choice and counter your concerns.
Q: Is the Spree Commerce platform too complicated for my business?
A: Generally, the answer should be something like It depends on your business and your goals. Actually, the idea behind Spree as a free e-commerce platform is to bring a product that appears to be as simple and easy to use as possible.
So with our Storefront we give a 100% guarantee that you’ll find it easy to:
- manage your products.
- configure tax rates in different zones.
- adjust shipping methods.
- optimize SEO.
- connect external solutions (Jirafe, Amazon, Zendesk, Salesforce etc.).
- and much more!
Although we have created a detailed guide on using our web interface, our practice shows that most of our clients are very good at figuring its functionality intuitively on their own.
However, keep in mind that you will still require a professional team of Spree Commerce developers to make a unique design for your store and set the platform up for your specific case. To do this, you can either turn to professional Ruby developers or take advantage of our expert customization services.
Q: What should I know to start? What if I get stuck at some point?
A: For such questions we created a spectacular online documentation section. Save this link to your bookmarks and check it whenever you have any question regarding the functionality of Spree Commerce.
Although we tried to cover as many details as possible in our guides, every case is unique, so don’t hesitate to contact us. Our core Spree Commerce team is always ready to help you and provide with 24/7 support.
Q: Is Spree indeed a free e-commerce platform? How do you guys monetize your solution?
A: The Spree Storefront is indeed an open source project, so you can download and use it for free. Our team earns a living by providing guided support for using Wombat, which is an operational system integrating all parts of your e-commerce business in one place. The price varies based on the number of orders you’re going to operate per month. We also offer expert customization of your Spree store on a regular basis.
Q: How can I understand that your solution is better than the one I currently use?
Usually our clients switch to Spree Storefront when they are no longer satisfied of how quickly their solution can process the info and load the store. Here are the most popular reasons for this:
- The store processes more orders than before and requires too much efforts to be optimized.
- The solution provides not enough safety and security options to stick with it any longer.
- The platform does not provide enough documentation to build a stable and reliable store for your needs, so you constantly need to advise with support engineers.
Sometimes our clients find that Spree Storefront provides more flexibility and extensions for their specific needs. Thanks to our open source approach, we have an amazing community with over 700 contributors from all over the world trying to make Spree the best e-commerce platform available!
In other cases our clients just need a solution that can process huge number of orders. For instance, the co-founder of Spark Solutions Michal Faber created a Spree-based marketplace and told that it was successfully handling... 15.000 requests per minute!
Read more here
