VLT Labs Logo

VLT Labs Developer Handbook

All the do-s and don't-s.

v3.1.4


Introduction

Objective

The objective of this onboarding program is to create developers that will need minimum hand holding at the end of Week 2, and are self sufficient at solving simple and moderate problems

    Program Summery

  • Total program takes 2 weeks.
  • Week 1 is spent on Codeschool.
  • Week 2 is spent on building a rails app.
  • Week 3 codebase training for existing project if user is on existing project.
  • If the dev can finish Codeschool earlier, the developer can begin the rails app earlier.

Be careful! These rules are meant to make you a better programmer.
Follow them as they will be used in your code reviews

Onboarding - Getting Started 662-779-0927

    Week 1

  • Assigned a mentor from VLT Labs, mentor should guide mentee technically and also professionally.
  • Complete RAILS path on codeschool, this includes
    • Try ruby
    • Ruby bits
    • Ruby bits part 2
    • Rails for zombies redux
    • Rails for zombies 2
    • Rails 4 zombie outlaws
    • Surviving APIs with rails
    • Rails 4 patterns
    • Rails testing for zombies
    • Testing with rspec

    Week 2

  • Create a blog following the following process
                                                    $ rails new MyBlog --skip-test-unit --skip-bundle --skip
                                                
    • Get the gemfile, ruby version and gemset file, from here.
    • Modify the 3 files for the latest stable versions of the software.
  • The User story for the blog is in Appendix A
  • The mentor teaches dev how to use things like pry, better-errors, data-cleaner and other tools
  • At the end of the week, the developer will have to give a demo on his blog to his mentor and 3 other devs/managers from VLT Labs
  • The developer then has to take the suggestions and comments into account and fix them over the next 2 weeks, and give a new demo to his mentor in Week 4.
  • The mentor signs off on the project.
  • But all intents and purposes, the developer’s training is considered complete on Week 2 and is to work on live projects starting on Week 3

Appendix A: User Story

  • Bob is the user persona, bob is a young 16 year old boy who enjoys social media and likes to write.
  • Bob wants to sign in either with an email/password combo or with a social authentication like facebook
  • Bob wants to write a blog post and share it with his friends on facebook
  • Bob wants to have a nickname and be able to modify his profile photo on the blog
  • Bob wants to have some control over his privacy, sometimes he doesn’t want to share his blog post with his friends and family

    Week 3

  • Existing codebase training for devs who are being assigned to existing projects.
  • If dev is waiting on project to start, dev is immediately assigned to team with most capacity to train dev.

Tools to use #back to top

Every engineer needs tools to get the job done. Many tools can do many things but with the right tools you can get the job done faster and ensure standards are met.

Here is a list of of tools that you should use, take your time to explore them and get familiar around.

Development Process #back to top

Product Development

We are VLT Labs. We have worked with over fifty of product teams within Malaysia, from individual founders who are self-funded, to large multi-national organizations. We have also created our own products and dozens of libraries.

This is our playbook. It details how we make successful web and mobile products, and also how we run our company. It's filled with things we've learned based on our own experience and study of others' experiences.

Labs Process


Software Development

At VLT Labs we start writing code once the software architecture has been decided, along with the UI/UX design depending on the complexity of the project.

Below is a clearview of labs development proecess and here's a quick outline:

  • All developers commit their code into a private repository hosted on GitLab.
  • The developer will initiate a merge request.
  • The The project lead will then review the code and approve the merge request if it passes our standards and guidelines.
  • Once the request has been merged the code will automatically be push onto staging environment.
  • When a new build is ready, the project lead will create a release and push the code onto the production environment.
  • We always follow the "blue/green" production environment to ease the release of new features.

Labs Process


Protocols

The following rules exist in order to maintain our products quality. study them carefuly, understand them and make sure you follow them.

  • Follow Git Flow methodology, a branch for every new feature.
  • Commit your code by 5.30pm everyday, regardless whether it's finished.
  • Do not leave the office without commiting your code.
  • Deploy new releases by Thursday.
  • Do not deploy new releases to production on Fridays.
  • Always write tests, and improve your tests.
  • Do not merge without running the tests.
  • Do not merge code that has no tests.
  • Only project lead can merge to master branch.
  • Always automate deployment process.
  • Share your experience with the team.

Guides (401) 223-9085

This is a brief guidlines for the tools we use on daily basis, you can access the complete list of guidelines on our public github repo.

View the full list

Code Formatting

  • Avoid inline comments.
  • Break long lines after 80 characters.
  • Delete trailing whitespace.
  • Don't include spaces after (, [ or before ], ).
  • Don't misspell.
  • Don't vertically align tokens on consecutive lines.
  • If you break up a hash, keep the elements on their own lines and closing curly brace on its own line.
  • Indent continued lines two spaces.
  • Indent private methods equal to public methods.
  • If you break up a chain of method invocations, keep each method invocation on its own line. Place the . at the beginning of each line.
  • Use 2 space indentation (no tabs).
  • Use an empty line between methods.
  • Use empty lines around multi-line blocks.
  • Use spaces around operators, except for unary operators, such as !.
  • Use spaces after commas, after colons and semicolons, around { and before }.
  • Use Unix-style line endings (\n).
  • Use uppercase for SQL key words and lowercase for SQL identifiers.

Naming Convention

  • Avoid abbreviations.
  • Avoid object types in names (user_array, email_method CalculatorClass, ReportModule).
  • Prefer naming classes after domain concepts rather than patterns they implement (e.g. Guest vs NullUser, CachedRequest vs RequestDecorator).
  • Name the enumeration parameter the singular of the collection.
  • Name variables created by a factory after the factory (user_factory creates user).
  • Name variables, methods, and classes to reveal intent.
  • Treat acronyms as words in names (XmlHttpRequest not XMLHTTPRequest), even if the acronym is the entire name (class Html not class HTML).
  • Suffix variables holding a factory with _factory (user_factory).

Organization

  • Order methods so that caller methods are earlier in the file than the methods they call.
  • Order methods so that methods are as close as possible to other methods they call.

    Ruby on Rails

  • Avoid member and collection routes.
  • Use private instead of protected when defining controller methods.
  • Name date columns with _on suffixes.
  • Name datetime columns with _at suffixes.
  • Name time columns (referring to a time of day with no date) with _time suffixes.
  • Name initializers for their gem name.
  • Order ActiveRecord associations alphabetically by association type, then attribute name. Example.
  • Order ActiveRecord validations alphabetically by attribute name.
  • Order ActiveRecord associations above ActiveRecord validations.
  • Order controller contents: filters, public methods, private methods.
  • Order i18n translations alphabetically by key name.
  • Order model contents: constants, macros, public methods, private methods.
  • Put application-wide partials in the app/views/application directory.
  • Use def self.method, not the scope :method DSL.
  • Use the default render 'partial' syntax over render partial: 'partial'.
  • Use link_to for GET requests, and button_to for other HTTP verbs.
  • Use new-style validates :name, presence: true validations, and put all validations for a given column together.
  • Routes

  • Avoid the :except option in routes.
  • Order resourceful routes alphabetically by name.
  • Use the :only option to explicitly state exposed routes.

    Swift

  • Prefer structs over classes wherever possible
  • Default to marking classes as final
  • Prefer protocol conformance to class inheritance
  • Break long lines after 100 characters
  • Use 2 spaces for indentation
  • Use let whenever possible to make immutable variables
  • Name all parameters in functions and enum cases
  • Use trailing closures
  • Let the compiler infer the type whenever possible
  • Group computed properties below stored properties
  • Use a blank line above and below computed properties
  • Group methods into specific extensions for each level of access control
  • When capitalizing acronyms or initialisms, follow the capitalization of the first letter.
  • When using Void in function signatures, prefer () for arguments and Void for return types.
  • Prefer strong IBOutlet references.
  • Avoid evaluating a weak reference multiple times in the same scope. Strongify first, then use the strong reference.
  • Prefer to name IBAction and target/action methods using a verb describing the action it will trigger, instead of the user action (e.g., edit: instead of editTapped:)

    Javascript

  • Prefer ES6 classes over prototypes.
  • Use strict equality checks (=== and !==) except when comparing against (null or undefined).
  • Prefer arrow functions =>, over the function keyword except when defining classes or methods.
  • Use semicolons at the end of each statement.
  • Prefer single quotes.
  • Use PascalCase for classes, lowerCamelCase for variables and functions, SCREAMING_SNAKE_CASE for constants, _singleLeadingUnderscore for private variables and functions.
  • Prefer template strings over string concatenation.
  • Prefer promises over callbacks.
  • Prefer array functions like map and forEach over for loops.
  • Use const for declaring variables that will never be re-assigned, and let otherwise.
  • Avoid var to declare variables.
  • Use a trailing comma after each item in a multi-line array or object literal, including the last item.

Career Path #back to top

The goal is to provide clarity on a career path that the DEVELOPER can follow and understand where they are in the ladder.

Dev

  • Focuses on software development work
  • More code than powerpoints
  • Strong modeling skills and analytical skills required to solve problems
  • Strong technical skills
Labs Process


Levels

Level 1 - Newbie Engineer

  • This is the coaching stage where we are training the candidate, everyone starts here and by the end of the 4 week training program is moved to Level 2 if he/she qualified.
  • Unless the candidate demonstrates higher skills he will be assessed accordingly.

Level 2 - Engineer

  • Handles most tasks independently.
  • Capable of handling SIMPLE tasks tasks independently. Requires coaching on MODERATE, CHALLENGING and HARD.

Level 3 - Engineer

  • Handles most tasks independently.
  • Capable of handling SIMPLE and MODERATE tasks independently without any help. Requires coaching on CHALLENGING and HARD.

Level 4 - Senior Engineer

  • Handles most tasks independently, but can't lead a project. The project is lead by a 5 on both roles.
  • Capable of handling SIMPLE, MODERATE and HARD tasks independently.
  • Knows when to look for help for CHALLENGING tasks.

Level 5 - Senior Engineer

  • Project Lead, handles all tasks independently.
  • Capable of handling SIMPLE, MODERATE, CHALLENGING and HARD tasks independently. Knows when to look for help.
  • Familiar with Labs Standards and guidelines.
  • Familiar with Deployment process.

Progression

Progression is only automatic from Level 1 to Level 2 at the successful completion of the training

Progression from then on is done at the request of the Level 2.

Progression should happen once every 6 to 12 months. Career growth slower than that requires looking into.

Progression from level 1 to level 5 is dependent on skills and knowledge base, from level 5 to level 10 requries experience from 1 to 10 years and will be carefully assessed.

To Level 1 - Newbie Engineer

Just Joined The Company

To Level 2 - Engineer

  • Successfully completed codeschool training
  • Successfully completed 1 week demo challenge
  • Successfully incorporated changes from demo into application

To Level 3 - Engineer

  • Successfully completed >5 projects or >5 major release cycles with >1 CHALLENGING or HARD problem
  • Has the confidence of the Level 2s that they have worked with
  • Has the confidence of the Level 3s that they have worked with
  • Has a sense of humor about themselves
  • Good time management skills, strong record of delivering projects/cycles on time
  • Strong work ethic, this means stays focused at work, delivers 8 hours of value in 8 hours.

To Level 4 - Senior Engineer

  • Successfully completed >5 projects or >5 major release cycles with >1 CHALLENGING or HARD problem
  • Has the confidence of the Level 2s that they have worked with
  • Has the confidence of the Level 3s that they have worked with

To Level 5 - Senior Engineer

  • Successfully completed >5 projects or >5 major release cycles with >1 CHALLENGING or HARD problem
  • Has the confidence of the Level 2s that they have worked with
  • Has the confidence of the Level 3s that they have worked with