Skip to content

exygy.markdown

Latest commit

 

History

History
128 lines (88 loc) · 5.51 KB

exygy.markdown

File metadata and controls

128 lines (88 loc) · 5.51 KB
layout post
title Exygy
published false
permalink exygy/
description Exygy - Codebrahma Partnership

Exygy - Codebrahma

We are a team who wants to write well-architectured, heavily tested code. And we cant live with bad code. Ruby is the language we speak. And the ruby code we write reads like english

Code-Quality

Well architectured codebases welcome change.

Most of our clients are startups who are interating rapidly. Therefore change is very frequent. And we make sure that our codebases are well architectured so that they are flexbile enough to welcome change.

We obsesses even with the quality of things unseen. For us code-quality matters.

We go beyond Lean Controllers Fat models. We make sure that our classes obey the Single responsiblity principle as much as possible. We take care to avoid data clumps, long methods and other code-smells. Inshort we keep track of the latest best practices of writing good code and follow it. We invest heavily in educating ourselves. We believe this is one of the areas we stand out.

Code quality is subjective and we dont promise subjective goals. We promise a codeclimate score > 3.6/4

Consistency

All our code is at least reviewed by one person before it goes into the master branch and more or less follows the github style

We take to the github style of writing ruby code, so that the code written by various members of the project all look the same.

Test Driven Development

We are rigourous practioners of writing our tests first. Here are the reasons

  1. Confidence. Writing Tests makes us insanely confident about our code.
  2. TDD forces you to write good code. Its impossible to test a 1000 line method, and hence you will start breaking it down. Design begins.
  3. Your Tests are your documentation. We used to comment our code to document it. But as we did quick fixes these comments grew out of date. We had to maintain these comments now. Instead of writing comments, write tests. They serve as executable documentation. Rspec reads like english and it is the best way to document your code.
  4. Jenkins. Continous Delivery. Quick Feedback. All you need is to push the code to github. If your test suite passes jenkins automatically deploys to the staging server
  5. Smooth Handover. When we deliver the code to clients' inhouse team, having a fully spec'd codebase removes the fear in the new developers. They dont have to worry if they will break anything. They can just make the changes and if the test suite passes, they are good to deploy.

We write both request specs and unit level specs. So if you want to know what a particular class is doing just open up its spec file.

Here is the video showing an example of a request spec.We show the integration specs which checks the sign up and sign in flow. These specs run on every commit and makes sure that the user sign up and sign in process is never broken.

Communication

We believe in over communication. We maintain pivotal tracker and a staging server. So that the client is always aware of the current status of the project

We do daily skype stand calls to give status updates and clarify doubts regarding the days work. So we make sure that the client knows that we are going in the right direction

Delivery on Time

We dont miss our deadlines. We have never missed our deadlines.

Open Source Contributions

We contribute to open source on saturdays... Here are our latest contributions

  1. Rails gem we built
  2. My contribution to jekyll 1
  3. My contribution to jekyll 2
  4. Viveks contribution to diaspora

Team

Vivek has been my team lead for a year now. He is actively involved in the project and takes care of the daily stand up calls (The diaspora contribution and the ARI FETCH plugin is the code he wrote). He consults me for architectural decisions. Thats the way it usually is. We do whatever is necessary for the project.

I will fly to meet you

I have a business visa to the US. I was there for the yC 2011 demo day. So if you need me there, for any reason whatsoever i will fly down.

Why we want to work with you

  1. I love the way you gave us the requirements. It took me only 10 minutes to get all of it.
  2. I love your honesty and transparency
  3. I am looking for a partner in the US, who can source projects regularly for us. And i think you are a perfect match. Clients like Google, zendesk and your transparency lure me to work with you

Why you should work with us

  1. Zero Worry. You dont need to manage us. You can give us the requirements and you can trust us to deliver the job on time and with quality. You can go ahead and build your business and we will deliver this job on time with excellent quality
  2. Quality. The quality of the code we write is something we pride on. It is very easy to maintain and read
  3. 100 % Money Back Offer. Give us a chance to work with you, and if you dont like our work or you arent satisfied, we will refund your money. Or you can pay us whatever you think is worth. We are sure, that you will be impressed by our work.
<style type="text/css"> .main-nav { visibility: hidden; } </style>