when a semantic tag can be used instead 22 | * use standard **landmarks** for defining: header, main, footer, etc. 23 | * use **headings** in the right order, always start from **h1** 24 | * form inputs should always be accompanied by **labels** 25 | * menus should start from a **

** element and contains _lists_ and _list items_ 26 | * use relevant **titles** for links - they are read by screen readers as users tab their way through the site 27 | * avoid titles like: "click here" or "read more", as they give no indication about the actual link 28 | * images should be accompanied by relevant **alt** texts 29 | * use _ARIA_ attributes only when there's no semantic alternative 30 | 31 | ### ✋ Interaction 32 | Never make assumptions about how your users interact with the website and make sure you have support for things like keyboard navigation. Some of these practices target people with motion difficulties, tremors and other problems limiting their interaction skills. 33 | 34 | * _links_ and _buttons_ should always be keyboard focusable (using the tab key) 35 | * _menus_ and _lists_ should be keyboard accessible (left-right for navigation) 36 | * modal windows have to close when pressing the Esc key 37 | * always show an outline when focusing elements - at a minimum, support keyboard outline with [what-input](https://github.com/ten1seven/what-input) 38 | * **focus** should be handled in parallel with click/tap events as well as with :hover pseudo-selectors 39 | * don't use tabindex > 0, allow a natural flow for the focus through the interface 40 | * trap focus when showing modal/overlays, so the user cannot navigate behind the foreground 41 | * handle focus after navigation - especially for SPA-like applications which are not reloading the page 42 | * ensure a **touch area** of at least 44px 43 | 44 | ### 🔨 Tools & Projects 45 | * Screen Readers 46 | * **Jaws** for Windows 47 | * **NVDA** 48 | * **VoiceOver** on OS-X/iOS 49 | * **Orca** for Linux 50 | * [lighthouse](https://developers.google.com/web/tools/lighthouse/) - performs audits in Chrome (the audit tab in devtools). 51 | * [axe-core](https://github.com/dequelabs/axe-core) - performs e2e automated tests for a11y issues, can easily be integrated in cypress or jest. 52 | * [tota11y](https://khan.github.io/tota11y/) - shows a11y validations on top of existing websites. 53 | * [alexjs](https://alexjs.com/) - catches insensitive and inconsiderate writing. 54 | * [eslint-plugin-jsx-a11y](https://github.com/evcohen/eslint-plugin-jsx-a11y) - ESLint plugin for static analysis of a11y violations. 55 | * [ReachUI](https://ui.reach.tech/) - a list of a11y first React components 56 | * [Inclusive Components](https://inclusive-components.design/) - a list of articles and examples of inclusive and accessibile components 57 | 58 | ### 📝 References 59 | * [A guide to color accessibility in product design](https://www.invisionapp.com/inside-design/color-accessibility-product-design/) 60 | * [Designing Accessible Content: Typography, Font Styling, and Structure](https://webdesign.tutsplus.com/articles/designing-accessible-content-typography-font-styling-and-structure--cms-31934) 61 | * [Designing Safer Web Animation For Motion Sensitivity 62 | ](https://alistapart.com/article/designing-safer-web-animation-for-motion-sensitivity/) 63 | * [Accessibility showcases of real projects](https://a11ywins.tumblr.com/) 64 | * [Web Accessibility Course on Udacity](https://eu.udacity.com/course/web-accessibility--ud891) 65 | * [Useful Accessibility Resources by Stefan Judis](https://www.stefanjudis.com/useful-accessibility-resources/) 66 | * [Status of a11y support in browsers](https://www.html5accessibility.com/) 67 | * [Building Accessible Menu Systems](https://www.smashingmagazine.com/2017/11/building-accessible-menu-systems/) 68 | * [Human Interface Guidelines for iOS](https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/adaptivity-and-layout/) 69 | * [Handling Touch Targets](https://a11yproject.com/posts/large-touch-targets/) 70 | * [WAI-ARIA Guidelines](https://www.w3.org/WAI/standards-guidelines/aria/) 71 | 72 | *** Credits go to [Alex Moldovan](https://github.com/alexnm/a11y-checklist) 73 | -------------------------------------------------------------------------------- /how-we-work/coding-guidelines.md: -------------------------------------------------------------------------------- 1 | ## The art of clean code and consistency 2 | 3 | Writing code is an essential part our day to day activity. While working together for several years now, we saw that adopting a single guideline for the entire team is very beneficial and powerful. Choosing between two or more ways of writing code can lead to a lot of [bikeshedding](https://en.wiktionary.org/wiki/bikeshedding). 4 | 5 | ### Styleguide 6 | 7 | We follow most of the [airbnb styleguide](https://github.com/airbnb/javascript), which we highly recommend you read and understand before coming to an interview or sharing some code with us. We adapted some of the rules to enhance readability based on some debated preferences of the team members. You can read more about our reasoning on [Alex Moldovan's FreeCodeCamp account](https://medium.freecodecamp.org/adding-some-air-to-the-airbnb-style-guide-3df40e31c57a). 8 | 9 | On our projects, we are using the following [ESLint config](https://github.com/FortechRomania/eslint-config-fortech) to make sure we all stick to the same guidelines. What's more, we make sure that code that does not pass the linter, does not end up in the central repository. 10 | 11 | ### Clean code 12 | 13 | On top of a healthy coding styleguide comes the craftsmanship for writing clean and reusable code. We are 100% oriented towards quality and resilience when writing code. In our view, clean code equals less time spent over time refactoring and keeping the codebase up to date. We strongly encourage everyone that joins or wants to join the team to get familiar as soon as possible with the main principles behind clean code, many of which are addressed in Robert Martin's [Clean Code: A Handbook of Agile Software Craftsmanship](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882). 14 | 15 | Briefly, here are the principles: 16 | 17 | 1. Use very descriptive names. Be consistent with your names. 18 | 19 | 2. A function should not do more than one thing. 20 | 21 | 3. SRP (Single Responsibility Principle): a class or module should have one, and only one, reason to change. 22 | 23 | 4. Stepdown rule: every function should be followed by those at the next level of abstraction (low, intermediate, advanced). 24 | 25 | 5. A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment. 26 | 27 | 6. The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification and then shouldn't be used anyway. 28 | 29 | 7. Flag arguments are ugly. Passing a boolean into a function is loudly proclaiming that this function does more than one thing. It does one thing if the flag is true and another one if the flag is false. 30 | 31 | 8. Write learning test when using third-party code to make sure it behaves the way you expect it to. And if codebase changes in time, at least you find out early enough. 32 | -------------------------------------------------------------------------------- /how-we-work/performance/checklist.md: -------------------------------------------------------------------------------- 1 | # Performance Checklist 2 | 3 | ## Introduction 4 | 5 | We see performance as an integral part of the quality of the software that we build. There's no need to re-emphasize the importance of performance in the modern web. We strongly believe that it is our duty to provide to our users a slick and fast UX, so we try to include performance optimizations in our regular working process. 6 | 7 | Here are a couple of areas that revolve around web performance. They will be later grouped into **front-end**, **back-end** and **tooling**, but for now let's look at where we can actually improve the performance of our web applications. 8 | 9 | * [Optimizing Critical Rendering Path](#optimizing-critical-rendering-path) 10 | * [Keeping the bundle size to a minimum](#keeping-the-bundle-size-to-a-minimum) 11 | * [Image Optimization](#image-optimization) 12 | * [Interactivity and Animations](#interactivity-and-animations) 13 | * [Backend & Server Optimizations](#backend-optimizations) 14 | * [Performance Tests and Tools](#performance-tests-and-tools) 15 | 16 | All these are considered in the realm of modern web development with frontend frameworks rendering complex applications and thin APIs serving the data. 17 | 18 | ## Optimizing Critical Rendering Path 19 | 20 | When we talk about the Critical Rendering Path, or CRP, we refer to the initial load time of a web application. We ask a few questions: 21 | * How fast does the user see something? 22 | * How fast does the user see something relevant? 23 | * How fast can the user interact with the page? 24 | 25 | Up until recently, the [First Meaningful Paint (FMP)](https://developers.google.com/web/tools/lighthouse/audits/first-meaningful-paint) used to be a reference point, however it got deprecated as it appeared not to be accurate in 20% of the cases. It was effectively replaced with the [Largest Contentful Paint (LCP)](https://web.dev/lcp/) - a metric that reports the render time of the largest [image or text block](https://web.dev/lcp/#what-elements-are-considered) visible within the viewport, relative to [when the page first started loading](https://w3c.github.io/hr-time/#timeorigin-attribute). A few points to consider are: 26 | 27 | #### Use Server Side Rendering 28 | Modern JS frameworks (Angular, React, Vue) support server side rendering, allowing the application to become **universal**. Here's a guide to implement [server side rendering in React](https://medium.freecodecamp.org/demystifying-reacts-server-side-render-de335d408fe4). SSR minimizes the time you wait for the first meaningful paint because your components render on the server and the client only needs to load HTML and CSS. This also ensures that we can defer loading JavaScript files. 29 | 30 | #### Defer JavaScript execution 31 | If the user doesn't need JavaScript to see the initial render, we can use the `defer` attribute on script tags. 32 | ```html 33 | 107 | 108 | 133 | 134 | 135 | ``` 136 | 137 | ### Resources 138 | * [Youtube Official Firebase Channel](https://www.youtube.com/user/Firebase) 139 | * [React Native Firebase](https://github.com/invertase/react-native-firebase) - most popular React Native and Firebase implementation (it supports Firestore as well). 140 | -------------------------------------------------------------------------------- /what-we-do/showcase/flowtype.md: -------------------------------------------------------------------------------- 1 | We're currently assessing [flowtype](https://flow.org/) as a static type analyzer tool. 2 | 3 | A few useful links to start with: 4 | * [Installation Guide](https://flow.org/en/docs/install/) 5 | * [Basic Primitives](https://flow.org/en/docs/types/primitives/) 6 | * [Cheat Sheet](https://www.saltycrane.com/flow-type-cheat-sheet/latest/) 7 | -------------------------------------------------------------------------------- /what-we-do/showcase/graphql.md: -------------------------------------------------------------------------------- 1 | # GraphQL 2 | 3 | ### Getting Started with GraphQL 4 | Before jumping into GraphQL you must understand what it is and that it comes as an alternative to traditional REST APIs. One important note is that GraphQL is not tied to any specific language or framework. It is just a protocol used for communicating between clients and servers. 5 | * [Understand what GraphQL is about](https://dev-blog.apollodata.com/the-basics-of-graphql-in-5-links-9e1dc4cac055) 6 | * Check the [official documentation](http://graphql.org/learn/) for basic concepts 7 | * Build your first server following [this egghead course](https://egghead.io/courses/build-a-graphql-server) 8 | 9 | ### GraphQL and Mongo 10 | Once you've built your first GraphQL server you can check this article with a nice and simple example on how to connect the `query` and `mutation` resolvers to a Mongo database. 11 | * [Using GraphQL with MongoDB](https://www.compose.com/articles/using-graphql-with-mongodb/) 12 | 13 | ### GraphQL and Apollo 14 | This 8-part article is a great reference to start building a React app powered by a GraphQL backend. **Apollo** is an easy-to-use client for GraphQL which allows you to write queries and mutations on any frontend application in order to communicate with a GraphQL endpoint. This series of articles goes through the basic functionalities exposed by **React-Apollo**, the library used for connecting React apps to GraphQL. 15 | * [Getting started with React-Apollo](https://dev-blog.apollodata.com/full-stack-react-graphql-tutorial-582ac8d24e3b) 16 | 17 | **Notes** 18 | 19 | Be aware that GraphQL and Apollo are at new versions at the moment so setup might be a bit different. Took me a while to figure out exactly how to do it. The recommended approach is to visit the [oficial documentation](https://www.apollographql.com/docs/react/basics/setup.html) for setting up `React-Apollo`. 20 | 21 | The suggested way for first time users is 22 | ``` 23 | npm install apollo-client-preset react-apollo graphql-tag graphql --save 24 | ``` 25 | 26 | And then 27 | 28 | ```javascript 29 | import { graphql, ApolloProvider } from "react-apollo"; 30 | import ApolloClient from "apollo-client"; 31 | import gql from "graphql-tag"; 32 | import { HttpLink } from "apollo-link-http"; 33 | import { InMemoryCache } from "apollo-cache-inmemory"; 34 | 35 | const client = new ApolloClient( { 36 | link: new HttpLink( { uri: "" } ), 37 | cache: new InMemoryCache( ), 38 | } ); 39 | ``` 40 | 41 | Also, keep in mind that you to set your express server to allow cross-origin requests since the backend and the frontend will run on different ports. You can easily to that with the `cors` package in express. 42 | 43 | ``` 44 | const cors = require( "cors" ); 45 | 46 | server.use( "*", cors( { origin: "http://localhost:3000" } ) ); 47 | ``` 48 | 49 | Also please note that when adding **subscriptions**, the interface of the `apollo client` setup is changed drastically. You can follow the [example code from this repo](https://github.com/alexnm/graphql-playground) that I created to make it work. You can easily follow the [official documentation](https://www.apollographql.com/docs/react/features/subscriptions.html) also. 50 | 51 | The rest of the code is similar with what is described in the article. 52 | 53 | Also worth reading while getting deeper into React-Apollo: 54 | * [Caching](https://www.apollographql.com/docs/react/features/caching.html) 55 | * [Optimistic UI](https://www.apollographql.com/docs/react/features/optimistic-ui.html) 56 | * [Using Fragments](https://www.apollographql.com/docs/react/features/fragments.html) 57 | 58 | ### Demo 59 | 60 | [Here is a demo app](https://github.com/alexnm/graphql-playground) I built using the major features of `GraphQL`. 61 | 62 | ### Further reading 63 | 64 | * [Getting started with React and Apollo](https://www.howtographql.com/react-apollo/1-getting-started/) 65 | * [Building a real-time chat with GraphQL](https://blog.graph.cool/how-to-build-a-real-time-chat-with-graphql-subscriptions-and-apollo-d4004369b0d4) 66 | * [Using Vue with Apollo](https://medium.com/yld-engineering-blog/using-vue-with-apollo-65e2b1297592) 67 | -------------------------------------------------------------------------------- /what-we-do/showcase/nginx.md: -------------------------------------------------------------------------------- 1 | # Nginx 2 | 3 | ### Getting Familiar With NGINX 4 | NGINX is a free, open-source, high-performance HTTP server and reverse proxy. We use their official [website](http://nginx.org/en/) to read about their latest updates. We use also [Digital Ocean](https://www.digitalocean.com) for learning purposes. 5 | This article on [understanding nginx server and location block selection algorithms](https://www.digitalocean.com/community/tutorials/understanding-nginx-server-and-location-block-selection-algorithms) might help you start your work in this direction. This [beginner's guide from nginx](http://nginx.org/en/docs/beginners_guide.html) might also come in handy. 6 | 7 | We choose NGINX servers because: 8 | * Open-Source & Free 9 | * Addresses [C10k problem](http://www.kegel.com/c10k.html) 10 | * Easy to install. Easy to configure 11 | * Designed for big apps but also suitable for small ones 12 | * Scales in all directions: from the smallest VPS to large clusters of servers 13 | * Not threaded to handle requests 14 | * Small and predictable amounts of memory under load 15 | 16 | #### How To Install 17 | Depending on the operating system: installation steps described [on the nginx wiki](https://www.nginx.com/resources/wiki/start/topics/tutorials/install/). 18 | 19 | ##### Installation example for Ubuntu 16.04 20 | 21 | ``` 22 | deb http://nginx.org/packages/ubuntu/ xenial nginx 23 | deb-src http://nginx.org/packages/ubuntu/ xenial nginx 24 | sudo apt-get update 25 | sudo apt-get install nginx 26 | ``` 27 | 28 | #### Server Configuration Structure 29 | * /etc/nginx: contains all configuration files. 30 | * /etc/nginx/nginx.conf: the main/universal NGINX configuration file. 31 | * /etc/nginx/sites-available/: the directory where all "server blocks" can be stored. NGINX will not use the configuration files found in this directory unless they are linked to the sites-enabled directory. Typically, all server block configuration is done in this directory, and then enabled by linking to the other directory. 32 | * /etc/nginx/sites-enabled/: The directory where all enabled "server blocks" are stored. Typically, these are created by linking to configuration files found in the sites-available directory. 33 | 34 | 35 | #### How To Use - Main Commands 36 | * Start server 37 | ``` 38 | sudo /etc/init.d/nginx start 39 | or 40 | sudo systemctl start nginx 41 | ``` 42 | * Check Status 43 | ``` 44 | systemctl status nginx 45 | ``` 46 | * Stop server 47 | 48 | This stop option implies that a fast/forced shutdown is applied i.e. the process is killed instantly even if there is a current request in progress. 49 | ``` 50 | nginx -s stop 51 | or 52 | kill - s processId ( ps aux | grep nginx ) 53 | ``` 54 | * Quit server 55 | 56 | This stop option graceful shuts down the server. That means that it waits for the worker processes to finish serving current requests. 57 | ``` 58 | nginx -s quit 59 | ``` 60 | * Test/Check for correct syntax the configuration from the NGINX config file. 61 | ``` 62 | nginx -t 63 | ``` 64 | * Restart service 65 | ``` 66 | sudo systemctl restart nginx 67 | ``` 68 | * Reload the configuration file 69 | ``` 70 | sudo systemctl reload nginx 71 | or 72 | nginx -s reload 73 | ``` 74 | * (Re)open log files 75 | ``` 76 | nginx -s reopen 77 | ``` 78 | 79 | #### Main Configuration Blocks 80 | * [`http`](http://nginx.org/en/docs/http/ngx_http_core_module.html#http) - main configuration from the `nginx.conf` file; in this block the universal configuration is done. 81 | * [`server`](http://nginx.org/en/docs/http/ngx_http_core_module.html#server) - block that contains all the configuration for the virtual server. 82 | * [`listen`](http://nginx.org/en/docs/http/ngx_http_core_module.html#listen) - describes addresses and ports that accept connection with the server. In this block can be defined one of the following: 83 | 84 | - an ip/address/port combination 85 | - a lone IP what will listen the default port 80 86 | - a lone port that will listen every address on that port 87 | - a path to other unix socket 88 | 89 | * [`server_name`](http://nginx.org/en/docs/http/ngx_http_core_module.html#server_name) - indicates all server names. With this block you can define several names for your server. Keep in mind that the 1st name listed is the primary name. The server can be a string that can contain `*`, `~`, or regex. 90 | * [`ssl_certificate`](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate) & [`ssl_certificate_key`](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate_key) - blocks applicable for https; they indicate the paths to ssl certificates. 91 | * [`error_log`](http://nginx.org/en/docs/ngx_core_module.html#error_log), http://nginx.org/en/docs/http/ngx_http_log_module.html#access_log - blocks used to indicate the path where logs will be stored. To specify the format of the log, [`log_format`](http://nginx.org/en/docs/http/ngx_http_log_module.html#access_log) directive can be used. 92 | * [`location`](http://nginx.org/en/docs/http/ngx_http_core_module.html#location) - block with config used for handling requests for different resources and URIs for the parent server. 93 | * [`gzip`](http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip) - block used for on-the-fly gzip compression to limit the amount of bandwidth used and speed up some transfers. This block can be configured in such matter that only files bigger than a certain size are included in the gzip compression - only relevant compression is done and the transfer process is done rapidly. 94 | * [`root`](http://nginx.org/en/docs/http/ngx_http_core_module.html#root) - sets the root directory for requests. That means that the path from the root directory will be the first one used to search for a file. In case of an request, to obtain the path of a requested file, NGINX appends the request URI to the path specified by the root directive. This directive can be used at any level within the http, server, or location contexts. 95 | * [`index`](http://nginx.org/en/docs/http/ngx_http_index_module.html#index) - defines what will be used as index; it is nested inside location for internal redirect. 96 | * [`proxy_pass`](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass) - if specified inside a location, this directive passed a request to an HTTP proxied server. 97 | * [`try_files`](http://nginx.org/en/docs/http/ngx_http_core_module.html#try_files) - checks the existence of files in the specified order and uses the first found file for request processing; the processing is performed in the current context. 98 | * [`alias`](http://nginx.org/en/docs/http/ngx_http_core_module.html#alias): defines a replacement for the specified location. 99 | 100 | #### Static Server Configuration Example 101 | The following configuration example can be used on an NGINX server that only serves static content. The example is focused on the way one should define the paths that are searched to find requested files, and on how to set up index files. 102 | The first `root` directive defined like below means that it applies to all location blocks where the root directive is not included to explicitly redefine the root/over-written. For example, take a look on the `location` directive definitions: for every request of an image, NGINX searches for a URI that starts with /images/ in the /www/data/images/ directory on the file system. But, in the case, of a request asks for a .mp3 file ( i.e. the URI ends with the .mp3 extension ), NGINX instead searches for the file in the /www/media/ directory because it is defined in the matching location block. 103 | If a request ends with a slash, NGINX treats it as a request for a directory and tries to find an index file in the directory. The index directive defines the index file’s name (the default value is `index.html`). One can list more than one filename in the index directive. NGINX searches for files in the specified order and returns the first one it finds. 104 | 105 | ``` 106 | server { 107 | root /home/work; 108 | 109 | location / { 110 | index index.html index.php; 111 | } 112 | 113 | location /images/ { 114 | } 115 | 116 | location ~ \.(mp3) { 117 | root /home/media; 118 | } 119 | } 120 | ``` 121 | 122 | #### Dynamic Server Configuration Example 123 | The following configuration example is a basic NGINX configuration used for two UI applications - an user app and an admin dashboard. The applications were built with create-react-app package do the deploy process was done following the instructions from this [link](https://medium.com/@johnbrett/create-react-app-push-state-nginx-config-a9f7530621c1). 124 | On HTTP, the server will listen to the default port `80`. When on HTTPS, the `443` port will be listened and the ssl certificates will be checked. The server's name can be is called `myserver`. For logging all requests and the errors encountered, the path from local storage is setup. The `root` block points to the folder where the user app is stored. There are two `location` blocks used in this configuration file. The first one (`location /api/`) handles the requests to an HTTP proxied server - in this case the backend server. The second one(`location /admin`) handles the requests to the dashboard app. 125 | 126 | ``` 127 | server { 128 | listen 80; 129 | server_name myserver.ro www.myserver.ro; 130 | return 301 https://$server_name$request_uri; 131 | } 132 | 133 | server { 134 | listen 443 ssl; 135 | server_name myserver.ro www.myserver.ro; 136 | ssl_certificate /etc/nginx/ssl/myserver_ro.crt; 137 | ssl_certificate_key /etc/nginx/ssl/myserver.key; 138 | 139 | access_log /var/log/myserver/access.log; 140 | error_log /var/log/myserver/error.log; 141 | 142 | root /home/work/ui/build_final; 143 | try_files $uri /index.html; 144 | 145 | location /api/ { 146 | proxy_pass http://127.0.0.1:3000; 147 | } 148 | 149 | location /admin { 150 | alias /home/work/dash/build_final; 151 | try_files $uri /admin/index.html; 152 | } 153 | } 154 | ``` 155 | 156 | #### Resources 157 | * [NGINX Official Website Documentation](https://nginx.org/en/docs/) 158 | * [NGINX Tutorial](http://nginx.org/en/docs/beginners_guide.html) 159 | * [Udemy Tutorial - NGINX Fundamentals ](https://www.udemy.com/nginx-fundamentals/learn/v4/overview) 160 | * [Digital Ocean Tutorial - Understanding NGINX Server and Location Block Selection Algorithms](https://www.digitalocean.com/community/tutorials/understanding-nginx-server-and-location-block-selection-algorithms) 161 | * [Static Server configuration](https://www.nginx.com/resources/admin-guide/serving-static-content/) 162 | * [Basics in Server Configuration](https://linode.com/docs/web-servers/nginx/how-to-configure-nginx/) 163 | * [Dynamic Virtual Hosts](https://gist.github.com/cbmd/4247040) 164 | -------------------------------------------------------------------------------- /what-we-do/showcase/vue.md: -------------------------------------------------------------------------------- 1 | # Vue.js 2 | 3 | ### Quick links 4 | * [vue-cli](https://github.com/vuejs/vue-cli) - starting from a standard template 5 | * [official guide](https://vuejs.org/v2/guide/) - starting from scratch 6 | * [awesome vue](https://github.com/vuejs/awesome-vue) - a list of curated materials on Vue 7 | * [vue templates for cli](https://github.com/vuejs-templates) 8 | * [5 part article on getting started](https://css-tricks.com/guides/vue/) 9 | * [vue devtools](https://github.com/vuejs/vue-devtools) 10 | * [vue.js and serverless](https://css-tricks.com/creating-vue-js-serverless-checkout-part-one/) 11 | 12 | ### Fresh start 13 | In case you are new to the world of frontend libraries and frameworks, I think the [official documentation](https://vuejs.org/v2/guide/) is the right way to start. Forget about the vue-cli and the other tools around the ecosystem and get up to speed with vue in a regular old fashion single html file. 14 | 15 | ### With prior experience 16 | If you worked with similar frontend frameworks before (ex: React, Angular) and you are aware of the modern JavaScript ecosystem (ex: Webpack, ES2015, Babel), then the *vue-cli* is the best option to get started fast with Vue. 17 | 18 | We highly recommend you follow this [5-part article](https://css-tricks.com/guides/vue/) written by Sarah Drasner which takes you through the entire Vue ecosystem. I strongly advise you follow along and write your own code, while playing around with the Vue components. [Vue Devtools](https://github.com/vuejs/vue-devtools) is also a great addition to your browser. 19 | 20 | Additional information about Vue Components and specifically on [methods, computed and watches](https://css-tricks.com/methods-computed-and-watchers-in-vue-js/) 21 | 22 | #### Vuex 23 | If you have some experience with Redux, you can have a look at how Vuex works in conjunction with Vue. [The official guide](https://vuex.vuejs.org/en/) is a good way to start. You will need to understand what mutations and actions are because they differ a bit from what you may know from Redux. A good guide can be found on [vueschool.io](https://vueschool.io/courses/vuex-for-everyone) (free course). 24 | 25 | #### Things to follow 26 | A couple of points where an in-depth understanding is needed in order to build a large scale application: 27 | * [ ] working with forms 28 | * [ ] integrating APIs 29 | * [ ] server side rendering 30 | * [ ] eslint config for Vue 31 | -------------------------------------------------------------------------------- /what-we-do/technical-radar.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FortechRomania/js-team-showcase/72ba01948cde3cb2726b10d52424e4f25b409666/what-we-do/technical-radar.png -------------------------------------------------------------------------------- /who-we-are/README.md: -------------------------------------------------------------------------------- 1 | # Who we are 2 | We are a growing team of professionals focusing our skills and efforts around the JavaScript ecosystem (and not only). We work in a collaborative way on multiple projects, while still making sure everyone in the team adheres to our common vision and culture. 3 | 4 | We wanted to write a few lines about the team name `Cake for Breakfast` but it’s self-explanatory anyway and we were too busy... 👇 5 | 6 |

7 | 8 | ### You are always part of the team 9 | Before we start talking about *what* and *how* we work, let's make something clear: at any time, in any setup, under any circumstances, we are part of the **same team**. This is the corner stone of our team culture. Each and every member of the team is **equal** to the other and we all contribute to the development of the team. It doesn't matter if we work in different teams, on different projects with different customers. At the end of the day, we are part of the same team. 10 | 11 | Read more about our [team activities](https://github.com/FortechRomania/js-team-showcase/tree/master/who-we-are/inside-the-team.md). 12 | 13 | ### Why culture matters 14 | 15 | Team work is a winner in today's software development world, that's a no brainer. Everyone understands the importance of team work and collaboration, but a team is more than the individuals that form it and the relations between them. The team exists outside the context of each individual and the team carries on, as long as the culture formed around it is strong. A strong team culture means that no individual is irreplaceable, but at the same time all individuals are valuable and an integral part of the team. 16 | 17 | We work in an environment where everyone collaborates, help and support are unconditioned and the needs of the team come before the needs of the individual. 18 | 19 | ### A culture built on mentoring 20 | 21 | We believe mentoring is the key to success. It doesn't matter if you have 10 years of experience or 3 months, in our team you will be both a mentor and a mentee. From our [junior development program](https://github.com/FortechRomania/js-team-showcase/tree/master/we-train/junior-development-program) to our montly initiatives of learning and development, everything we do is based on learning, teaching and sharing. Some of our initiatives are also based on giving back to the community, so be ready to embrace mentoring and teaching as a primary activity. 22 | 23 | ### Our core values 24 | 25 | Althought our team is built around technology and the JavaScript ecosystem, our core values are not technology focused. They represent the sum of the human traits that we value most. 26 | 27 | #### Passion 28 | 29 | The main driver of most of our activities. It's hard to work in the software industry without passion. Hard work and skills will solve one problem at a time, passion will deliver the end result. 30 | 31 | #### Honesty 32 | 33 | We are not superstars, we are not all-knowing gods, everyone has flaws, gaps in knowledge and lack of understanding in all sorts of areas. We value honesty first and as long as there's willingness to learn and adapt, we can work with you. We do not value a cocky attitude towards colleagues and technology. 34 | 35 | #### Motivation 36 | 37 | Are willing to go the extra mile? Everyone has different incentives of motivation but we always value the positive motivation. Each team member is committed and engaged in what he or she does, whether it's about writing code, teaching others or any other endevour. 38 | 39 | #### Curiosity 40 | 41 | How much time do you spend exploring new things? Do you have a keen interest in technology and its evolution? Our wish is to empower people to try things out, to test new concepts, new tools and frameworks. Curiosity drives innovation and evolution. 42 | 43 | #### Perseverence 44 | 45 | Without it, dealing with complicated tasks becomes a burden. It's not only about hard work, it's also about asking all the right questions, getting deeper into the code to find the true source of a problem or making sure you covered all the cases. 46 | -------------------------------------------------------------------------------- /who-we-are/inside-the-team.md: -------------------------------------------------------------------------------- 1 | # Inside the Team 2 | Besides working on the daily tasks, we give each member of the team a chance to get involved in additional activities as part of the regular working hours. There are 3 types of activites or initatives that we tackle, some of them are ongoing and some of them are happening one time: 3 | * personal development activities 4 | * internal company activities 5 | * external company activities 6 | 7 | ### Personal Development Activities 8 | While personal development should also be done during your own time, we try to offer as much time as possible for personal development during the working hours. We schedule together R&D, open-source or just learning activities that one takes ownership of. Let's say that for example that you want to learn [Vue](https://vuejs.org/) or you want to play a little with [GraphQL](http://graphql.org/). We plan this together with the rest of the team and you have a number of hours allocated to learning this during the working hours. The only condition is to prepare a dissemination of what you found out / learned during the time with the entire team, so that knowledge is distributed to all members. Similarly, you can opt-in to contribute to one of the open-source projects we started on [github](https://github.com/FortechRomania) or to start another one and we plan together some sessions with the team for analysis and review. 9 | 10 | ### Internal Company Activities 11 | This can vary from participating in tech interviews, to mentoring people as part of our [internship program](https://github.com/FortechRomania/js-team-showcase/blob/master/we-train/junior-development-program/). If you are more interested in teaching we are heavily involved in internal and external training activities, so we will definitely find time for this. We are also involved in developing some internal tooling for our support departments, so be ready for some potential work in that area. 12 | 13 | ### External Company Activities 14 | These are the kind of activities that are helping us indirectly by creating a stronger brand around the team/company. But also they can help you build a stronger brand for yourself. So this can vary from being involved into the tech-sales process at Fortech, to speaking at events and conferences and to creating blog posts or external content for our company. 15 | 16 | Overall, these activities are molding you into a better professional and are allowing you to try different types of responsibilities to see which one fits you better. -------------------------------------------------------------------------------- /who-we-are/making-a-career.md: -------------------------------------------------------------------------------- 1 | # Growth within our team 2 | 3 | As everybody else, we also have career paths defined for each team member, along with expectations for each phase you are in. For sure, we'll help you get where you want and expand your horizons. 4 | 5 | There are four main streams you can follow within our team: **Front-End JavaScript Engineer**, **Back-End JavaScript Engineer**, **Full Stack Javascript Engineer** or **QA Automation Engineer**. Each team member is encouraged to follow his/her passion and supported in doing so. 6 | 7 | For each stream we have a set of expectations defined. These expectations cover multiple areas: Team, Soft skills [ Communication, Attitude], Technical [Code, Architecture, Concepts, Technology] 8 | --------------------------------------------------------------------------------