Skip to content

Commit

Permalink
Merge pull request #22 from nodes-ios/mariusc-patch-1
Browse files Browse the repository at this point in the history
Updating the README to reflect 2020 situation
  • Loading branch information
mariusc authored Feb 14, 2020
2 parents 7d7e7a6 + 06ec37e commit 9c60878
Showing 1 changed file with 36 additions and 31 deletions.
67 changes: 36 additions & 31 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,66 +13,65 @@ We try to increase our contribution to the iOS developer community through:
- encouraging our team members to join iOS related meetups, groups and conferences
- encouraging our team members to speak at iOS events
- contributing back to some of the other open source libraries we use through issues and PRs
- encouraging our team members to write tech articles about any topic they desire on our [engineering blog](https://engineering.nodesagency.com/)
- encouraging our team members to write tech articles about any topic they desire on our [engineering blog](https://engineering.nodesagency.com/); if needed, we can also suggest topics for new articles

We create lots of apps for our clients. Most of those apps rely heavily on web APIs. We abstracted the common operations for working with web APIs, and that's how [Serpent](https://github.com/nodes-ios/Serpent) (formerly known as Serializable) and [Cashier](https://github.com/nodes-ios/Cashier) were born. Another issue that was common in all the apps we do was handling keyboard appearance events. This led to the appearance of [KeyboardHelper](https://github.com/nodes-ios/KeyboardHelper).

We are currently in the process of abstracting parts of our codebase into open source libraries that can be reused in other projects. As well as this, we are trying to change our way of thinking for current and future projects and when we encounter a feature whose implementation can be reused in other projects we try to implement it as a separate component which we open source. We are just beginning, and it is a big change, but this is what we aim for in the long run.


# Team meetings
Here are the recurring meetings the iOS team takes part in:

#### iOS Team Meeting
This is the main meeting in the iOS team, where we talk about the latest things happening in our team. General direction of the team, brief general team performance review, what people need help with, amount of workload, should we use or not _that_ framework, etc. This happens in the first Monday of each month.

#### Mobile Show and Tell Meeting
This is a monthly meeting, that occurs on the third Friday of every month. Members of the iOS and Android team talk about anything cool that they implemented recently. It could be using some new technology, some cool framework, a nice animation, a clever algorithm or anything similar to this. Traditionally, there's beer for presenters and attendees.
#### Friday Tech Talk
This is a monthly meeting, that occurs on the fourth Friday of every month. Anyone in the engineering team can talk about anything cool that they implemented recently. It could be using some new technology, some cool framework, a nice animation, a clever algorithm or anything similar to this. The meeting is held in the Copenhagen office, but if anyone from other offices wants to attend, we can enable a video call.

#### Quarterly Company Catch-up
#### Monthly Briefing

This is a quarterly meeting, where the board tells all the employees how the company did in the last quarter and what our targets and short, mid and long-term plans are. You'll find out if the sales and production are on track, below or ahead of target, and anything else relevant to the company. It's not only a presentation, feel free to ask questions.
This is a monthly meeting, where the management tells all the employees how the company did in the last month and what our targets and short, mid and long-term plans are. Topics covered are sales, projects, cases, tech, events, staff and others. The meeting is held in the Copenhagen office, but other offices can join in by video call.


# Your First Day

The IT department is responsible for setting up accounts and giving you access to the tools you need to do your job. The easiest way to contact the IT departmentis by using the `/halp` command on Slack.

# Your First Day
- Join [our private git](https://github.com/nodes-projects) and ask [Chris](https://nodes.slack.com/messages/@chco) to add you to the correct groups.
- Meet with the Head of iOS, your Team Manager (Lead Developer) and your Nodes Buddy. They will be your first persons of reference in the company. Use them as much as you need to get settled in, but also be considerate of their own time.
- Join [our private git](https://github.com/nodes-projects). Ask IT if you don't have access.
- Get the cert sign request and private key from [this private repo here](https://github.com/nodes-projects/keyring-ios). Add the private key to your Keychain and from now on, always use this certificate signing request when creating new certificates on the developer portal.
- Install the latest Xcode. Ideally, from the [Apple developer portal](https://developer.apple.com/download/more/) and not from the App Store. If you got it from the App Store, that's ok too.
- Get another iOS developer to invite you to our developer account.
- Get another iOS developer to invite you to our developer accounts.
- We want you to help us make great open source software. So get another iOS developer to invite you to [our GitHub organisation](https://github.com/nodes-ios). Make sure you enable your 2FA on GitHub. Our client projects are on [our private git](https://github.com/nodes-projects) and our public ones are on [GitHub](https://github.com/nodes-ios).
- Set up your git keys properly, so you can pull and push from both git servers.
- Ask an iOS colleague to invite you to Hockey
- You should have been invited to our Slack, Trello, and Postman accounts. Talk to [Jacob](https://nodes.slack.com/messages/@jafr) if you're missing access.
- Make sure to read the description of our [iOS stack on our engineering blog](https://engineering.nodesagency.com/our-stacks/ios/). That article goes hand in hand with this playbook here.
- You should have been invited to our Slack, JIRA, and Postman accounts. Ask IT if you don't have access.
- Make sure to read the [Nodes Handbook](https://docs.google.com/document/d/1E4ZyGqIKDttGlJ0c0rEkNy2lxP-n1PBwQzuaESbLnpw/edit) (private document). That is meant for all employees, and tells a bit of our history, how we got here, but also how we handle different tasks.
- We love eating cake, and we hope you do too. We'll use any excuse to do it. So we'll ask you to have [Simon](https://nodes.slack.com/messages/@siej) add your birthday to the calendar, so we can get you a big birthday cake and celebrate.
- We have Facebook groups for internal semi-official announcements. Ask a colleague to add you to the groups.
- We use [Happeo](https://app.happeo.com/home) for internal (semi)official announcements. Ask IT if you don't have access.

# Tools We Use

For employee management we use [BambooHR](https://nodesagency.bamboohr.com/home). Ask IT if you don't have access and the Chief People Officer if anything in there is unclear. Use this to request time off, register sick day and manage your personal info and banking info for salary pay.

Our main communication tool is [**Slack**](https://nodes.slack.com). We use this for daily communication.

Our main project management tool is [**Trello**](https://trello.com). Each project has its own Trello board. Always keep your project's Trello board up to date to reflect the current status of the project. We work in an agile manner and move fast, but the Trello board must clearly reflect the project's status. Ask [Simon](https://nodes.slack.com/messages/@siej) or your project manager if you have questions.
Our main project management tool is [**JIRA**](https://nodesagency.atlassian.net/jira/). Each project has its own JIRA board. Always keep your project's JIRA board up to date to reflect the current status of the project. We work in an agile manner and move fast, but the JIRA board must clearly reflect the project's status. Ask [Simon](https://nodes.slack.com/messages/@siej) or your project manager if you have questions.

[**Basecamp**](https://basecamp.com) is the main tool through which we interact with the clients. As a developer, normally you shouldn't have to deal that much with the clients directly or through Basecamp, but each project is unique and in some cases, developers are also added to Basecamp.
With the same JIRA account, you will also have access to Confluence, where you can find project-related documentation, and also internal documents.

[**Harvest**](https://nodes.harvestapp.com/) is the time tracking tool that we use. It helps us see how much time one person has worked on a project. Make sure to always harvest on the appropriate project. Ask the PM on which Harvest project you should track the time. We expect you to harvest 7.5 hours per day (it's ok to do more, if you want). Lunch time is not harvested, and it doesn't count towards the 7.5 hours per day. And if you want more detailed instructions on how to harvest, ask [Simon](https://nodes.slack.com/messages/@siej).
[**Harvest**](https://nodes.harvestapp.com/) is the time tracking tool that we use. It helps us see how much time one person has worked on a project. Make sure to always harvest on the appropriate project. Ask the PM on which Harvest project you should track the time. We expect you to harvest 7.5 hours per day (8 in Germany). Lunch time is not harvested, and it doesn't count towards the daily workhours. If you want more detailed instructions on how to harvest, check out the [company handbook (private document)](https://docs.google.com/document/d/1E4ZyGqIKDttGlJ0c0rEkNy2lxP-n1PBwQzuaESbLnpw/edit#heading=h.s0buhmnr48yl). You can also set up auto-harvesting in you Ournodes acount and it will automatically harvest your day on the project you're assigned to.

Harvest goes well hand in hand with [**Forecast**](https://forecastapp.com/). Use Forecast to see what project you're assigned to that day. Forecast is our planning tool, you can see what other people are assigned to, how long a project should take, when other people are on vacation, etc. On a higher level, Harvest and Forecast are very well integrated and Project Managers can see when a project goes over budget (more hours were harvested than allocated in Forecast). But that's not something you as a developer should care about.
Harvest goes well hand in hand with [**Forecast**](https://forecastapp.com/). Use Forecast to see what project you're assigned to that day. Forecast is our planning tool, you can see what other people are assigned to, how long a project should take, when other people are on vacation, etc. On a higher level, Harvest and Forecast are very well integrated and Project Managers can see if a project goes over budget (more hours were harvested than allocated in Forecast). But that's not something you as a developer should care about.

[**Postman**](https://www.getpostman.com/) is a great tool which helps you see and test web APIs. Our backend team uses Postman to test and document their APIs, so all the web APIs for our apps can be found in Postman. You can use it to see the different endpoints available, read their documentation or make requests to those endpoints. If you don't already have access, ask Casper or Jonas for an invite to Postman.
[**Postman**](https://www.getpostman.com/) is a great tool which helps you see and test web APIs. Our backend team uses Postman to test and document their APIs, so all the web APIs for our apps can be found in Postman. You can use it to see the different endpoints available, read their documentation or make requests to those endpoints. Ask IT if you don't have access.

Our design team uses Sketch. But you, as a developer, don't need to have Sketch installed. To ease the collaboration between designers and developers, we use [**Zeplin**](https://zeplin.io/). In Zeplin, you can see each screen in the design, get info about the sizes, padding, fonts, colours and also export assets for the mobile devices. You can also add notes in Zeplin and communicate with your designer directly on the project.

[**Charles**](https://www.charlesproxy.com/) is an HTTP proxy. You can set your phone / simulator to proxy through Charles and you can see all the API calls it made, you can inspect its requests or responses. It comes in very handy especially if you work with an external, poorly documented API.
[**Charles**](https://www.charlesproxy.com/) is an HTTP proxy. You can set your phone / simulator to proxy through Charles and you can see all the API calls it made, you can inspect its requests or responses. It comes in very handy especially if you work with an external, poorly documented API. Ask IT if you need a license.

For in-house distribution and crash reporting, we use [**Hockey**](https://www.hockeyapp.net/). You need to be invited to our company's account. Ask any other iOS developer for an invite. We're currently considering replacing Hockey with another similar service; we will update this document when/if we do it.
For in-house distribution and crash reporting, we use [**Firebase**](firebase.google.com/). Depending on the project, sometimes we only use TestFlight. Talk to your PM or with previous developers on that project.

We use [**Carthage**](https://github.com/Carthage/Carthage) to manage our dependencies on iOS. We chose Carthage over CocoaPods because for us, this is the one that brought the most advantages. We appreciate all the effort put into Carthage, as well as into CocoaPods, and we're looking forward to Swift Package Manager becoming the default dependency manager for iOS projects.

The way we do localisation in Nodes is a bit different than in other places. We use [**NStack**](https://nstack.io/), a service we built, which together with the [**NStack SDK**](https://github.com/nodes-ios/NStack) offers dynamic localisation for our apps. Go to [nstack.io](https://nstack.io/), log in with your Nodes account, select the app you need (or create a new one), go to "Translate" and add new translations or edit the current ones. A translation consists of a key (by which the string is recognised through the SDK) and one or more values (depending on the number of languages your app is translated to). The translations can be changed in NStack and the changes will reflect in the app without the need of an app update.
We had been using [**Carthage**](https://github.com/Carthage/Carthage) for a long time to manage our dependencies on iOS. We chose Carthage over CocoaPods because, for us, this is the one that brought the most advantages. But since we started using Firebase more and more and Google pushes strongly for CocoaPods, we sometimes use both in the same project. We appreciate all the effort put into Carthage, as well as into CocoaPods, and we're looking for the right time to switch to Swift Package Manager as our default dependency manager for iOS projects.

The way we do localization in Nodes is a bit different than in other places. We use [**NStack**](https://nstack.io/), a service we built, which together with the [**NStack SDK**](https://github.com/nstack-io/nstack-ios-sdk) offers dynamic localization for our apps. Go to [nstack.io](https://nstack.io/), log in with your Nodes account, select the app you need (or create a new one), go to "Localize" and add new translations or edit the current ones. A translation consists of a key (by which the string is recognized through the SDK) and one or more values (depending on the number of languages your app is translated to). The translations can be changed in NStack and the changes will reflect in the app without the need for an app update.


# Coding Guidelines
Expand All @@ -99,21 +98,27 @@ If you already have a project created an you just need to deploy it to Bitrise y

We also listed the most common issues when Bitrise is trying to make the builds. Please check the [common issues document](./ci/bitrise-issues-readme.md) if you are having some problems.

# Swift Migration Guide

A guide that shows how to migrate between different versions of Swift in our projects can be [found here](https://github.com/nodes-ios/Playbook/blob/master/migration-guide.md).

# Working with Remote Colleagues
Having one office in London, one in Copenhagen and one in Aarhus means you get to work with colleagues who are not in the same office as you are. If that is the case, make sure to rely as much as possible on Trello.

Having offices in 7 locations in Europe and Middle East means you get to work with colleagues who are not in the same office as you are. If that is the case, make sure to rely as much as possible on JIRA.

Our main means of communication inside the company is Slack. Use it wisely.

It helps a lot to try and change your mindset from synchronous communication to asynchronous communication. This means that you try to foresee any problems you might run into and ask about info for them before you actually run into them. Try not to get into a situation where you need an answer from someone in order to be able to continue.

Always have a good overview of what's left to be done and what you need in order to get it done.

If you need something (an image asset, some input from the PM, etc), make a Trello card asking for that.
If you need something (an image asset, some input from the PM, etc), make a JIRA card asking for that.

If there's some feedback from the client but you're not sure what to do about it, because there are multiple options, comment on the Trello card presenting what options there are, estimating how much time each of it would take and maybe advising towards one of it and ask the PM to take the decision.
If there's some feedback from the client but you're not sure what to do about it, because there are multiple options, comment on the JIRA issue presenting what options there are, estimating how much time each of it would take and maybe advising towards one of it and ask the PM to take the decision.

If in doubt, ask for a video call to discuss things. However, try to write down the notes / conclusions of the meeting, so you have them in writing. This helps you not forget anything and it also helps to align everyone on the team to the same conclusion.

# Further reading

* [VIPER architecture](./ViperArchitecture.md)
* [Modular architecture](./ModularArchitecture.md)
* [Code Modes](https://github.com/nodes-projects/readme/blob/master/mobile/ios/code-modes.md) (private document)
* [Securing your app](https://github.com/nodes-projects/readme/tree/master/security) (private document)
* Consider joining one or more of our [squads](https://github.com/nodes-projects/squads) (private document)

0 comments on commit 9c60878

Please sign in to comment.