# Teamwork Updates and stories from Teamwork.com Engine Room - Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## A Serverless Data Engineering Stack at Teamwork Using Go and AWS DevFeed: [A Serverless Data Engineering Stack at Teamwork Using Go and AWS]() Original publisher: [Read original article]() Author: Joe Minichino Published: 2021-10-19T13:58:52Z Content type: article Language: en Sources: [Teamwork]() Topics: [data-engineering](), [Serverless](), [Go Language](), [Amazon Web Services](), [AWS Lambda](), [Amazon S3](), [GitHub Actions](), [Docker](), [Apache Spark](), [airflow]() Tags: [airflow](), [aws](), [aws-athena](), [aws-lambda](), [data](), [data-engineering](), [docker](), [github-actions](), [go](), [golang](), [hadoop](), [s3](), [serverless](), [serverless-architecture]() ### AI overview This article describes Teamwork's serverless-oriented data engineering stack and the reasons for choosing it. It discusses AWS services including S3, Athena, Glue, QuickSight, Kinesis, and Lambda, with Go used for Lambda processing and GitHub Actions used for deployment. ### Source excerpt A real data lake. Traditional Data Engineering relies on products such as Airflow, Hadoop, Spark and Spark-based architectures, or similar technologies. These are still viable solutions for a number of reason, not least the fact that Data Engineers are few and far between, and the vast majority of them will be familiar in the above technologies or similar products/frameworks. Go Serverless I wrote an article about our tech stack, which includes S3, Athena, Glue, Quicksight, Kinesis etc. What is not immediately apparent is the serverless nature of our stack, which was a deliberate choice taken in the context of a Data Analytics department which was started as an experiment and had to pick its battles very wisely. Sysops, cluster / server management, CI/CD were not top of our list. Creating dashboards was. Also before Teamwork I had a nearly 2-year run working with a company that was entirely serverless in their set up AND mentality, and it was a career-changing experience. We worked prevalently with AWS Lambda when Lambda was a new toy, and we loved it. Finally, despite the "buzz" over Functional Programming being seemingly over, I am an arduous fanatic of it and of what it represents philosophically, a way to represent each problem in terms of an input, some transformation, an output and when possible, no side effects. NOTE: some of the tools I mention are not strictly serverless as much as they are fully managed (eg. Kinesis or Github Actions), but they still involve little or no sysops / devops. Serverless Processing: AWS Lambda Once upon a time you would have to settle for Node.js or Python to write Lambda code, but nowadays not only you can use a whole lot of runtimes, you can simply use your own docker image et voila', you're ready to go. In our case we are ready to Go, since at Teamwork Go(lang) is our programming language of choice. It's fast, easy to use, very safe and reliable, and given that it can complete the same operation faster than most other program ## Drawing icons using Core Graphics DevFeed: [Drawing icons using Core Graphics]() Original publisher: [Read original article]() Author: Diego Freniche Published: 2020-10-20T09:14:19Z Content type: tutorial Language: en Sources: [Teamwork]() Topics: [Graphics](), [Code](), [iOS](), [App]() Tags: [code](), [coregraphics](), [graphics](), [ios](), [playground](), [swift](), [swift-playgrounds](), [uikit]() ### AI overview A hands-on tutorial that uses Core Graphics in an iOS Playground to recreate a notebook icon from rectangles. It explains why vector-based drawing avoids the pixelation of bitmap icons and demonstrates the setup and initial implementation in code. ### Source excerpt Photo by Harpal Singh on Unsplash Sometimes you need to add an icon to your iOS app, The designer sends you that plain, simple icon. It can be a bitmap-based icon, like a PNG. Problem with those is they get blurry if zoomed in too much. So we can use a vector-based icon, like a Font Icon or a PDF. These are vector based, contains the instructions to draw the icon, not the icon itself. This way you can stretch the icon as much as you want, and you'll never see "big pixels" in your app. But what happens when you have a screen capture of your icon, but can't get any of these options? Well, this means it's time to dust-off your Core Graphics Skills and draw the icon by yourself. Won't even mention the horrible alternative of taking a screenshot and cutting the icon. Don't do it. I've done it and it's, indeed, horrible. Instead of telling you what Core Graphics is and how it works, we'll write code to solve a problem, so you can experiment and learn by doing. This is my preferred way of learning a new framework / library / language: try things, read a bit, try more stuff, read more seriously, watch videos, GOTO 1. The Notebook Icon The icon we'll try to recreate is this one: Represents a notebook with a background color that can change, a darker same color spine and a couple lines to represent the Notebook title. Create a new Playground We'll do all our coding inside a Playground. So we can get instant feedback. In the end, it will look like this: But for now let's create a Playground called Icons. It will just have one Playground page. Remove everything inside that page and just add: https://medium.com/media/b3fbc322df52879b716e63ffdfa765e0/href We'll use the first import to draw Views and use Core Graphics (it's included by UIKit). PlaygroundSupport will help us show nice previews of our work inside the Playground. Planning our work Looking at that notebook icon we can see it's composed of 4 rectangles: a big rectangle that forms the Notebook itself a spine rectangle a ## How to Build and Verify an App with the Teamwork Developer Portal DevFeed: [How to Build and Verify an App with the Teamwork Developer Portal]() Original publisher: [Read original article]() Author: Holly McGill Bracken Published: 2020-09-16T09:37:09Z Content type: tutorial Language: en Sources: [Teamwork]() Topics: [internal developer portal](), [API](), [Development](), [Authentication](), [OAuth](), [App]() Tags: [api](), [applications](), [authentication](), [building](), [developer](), [developer-portal](), [oauth](), [verification]() ### AI overview This tutorial explains how to create an app with the Teamwork Developer Portal and prepare it for verification and listing in Teamwork's integrations directory. It covers app details, product scopes, redirect URIs, OAuth authentication, and providing a way to test the app. ### Source excerpt Fast track the review process with these steps! At Teamwork, we know that integrations between the products you use most are essential to speeding up workflows and saving you time on switching between multiple apps. So when we released the Teamwork Developer Portal earlier this year, we were really excited to finally unleash the power of API driven solutions, and give you a dedicated space to build custom workflows with the tools you use everyday. Why build with us? Building an app to enhance the capabilities of Teamwork not only allows you to unleash the power behind automated processes, but it gives you access to our growing customer ecosystem. Did you know we have 20,000 + customers? Right now, we have a suite of 5 products, all with their own integrations to offer a seamless experience within our suite. With the ability to create your own apps, you have the opportunity to expand our suite, and grow with us. Whether you are trying to tackle an internal business process issue, or promote your company through integrations listings, we will support your development. So if you're interested in building an integration with Teamwork and would like to get listed in our integrations directory, then keep reading. Firstly, your app must be created in the Developer Portal -- you can learn more about how to get started here. When your app is ready to go, it's time to get it verified by Teamwork by reaching out to us at integrations@teamwork.com. For this step, it's essential that you provide us with a way to test your app. Since launching the Developer Portal, I've come across some common missing items in applications. So to speed up this process, I've outlined a checklist of everything you need to get a quick approval and listed on our integrations directory in no time. Let's get started!Verification Checklist 1. App Sanity Checklist It's important that we check some app details in the Developer Portal: Name and description must be clear and honest Icon must be clear and vis ## Prophecy: Teamwork's Data Lake DevFeed: [Prophecy: Teamwork's Data Lake]() Original publisher: [Read original article]() Author: Joe Minichino Published: 2020-07-17T11:41:10Z Content type: opinion Language: en Sources: [Teamwork]() Topics: [data lake](), [data-engineering](), [data](), [decision-making](), [big-data](), [Databases](), [Google Analytics](), [stripe]() Tags: [analytics](), [aws](), [big-data](), [data](), [data-engineering](), [data-lake](), [databases](), [decision-making](), [google-analytics](), [stripe]() ### AI overview Teamwork describes reevaluating its analytics approach because data was distributed across product databases and third-party services, making it difficult to connect leads, product usage, and revenue. The article argues that a data lake can make analytics and data-informed decision-making more practical, while clarifying that data lakes and big data are not limited to enterprise-scale environments. ### Source excerpt You need a Data Lake. The Context Teamwork has been around for more than 10 years. Starting out as a project management and work collaboration platform and later expanding into other areas, such as help-desk, chat, document management and CRM software. As the company has grown and evolved, data has grown, changed, expanded, diversified, fragmented, then changed again. Analytics in this landscape are not for the faint of heart. The Problem The issue at the base of the decision to start re-evaluating our analytics approach, at Teamwork, was because we have way too many data sources to make sense of all the data we collect. Much of the data ends up being "dark", underutilized, unleveraged. We have multiple databases shards, for each product, along with platform databases containing global customer information; and then we have 3rd parties such as Stripe, Marketo, Chart Mogul and Google Analytics to name the most important ones. We realized that making a connection between sales leads in Marketo, their usage of our products (GA and our DBs) and their revenue (our DBs, Stripe, Chart Mogul) was impossible. Well, it was possible, but incredibly painful and poorly automated, making it slow and error prone. And by addressing this problem we are getting a large number of benefits back, practically for free. You need Analytics Let's cut to the chase: you need analytics. No matter how big or small your business or enterprise is, you need analytics to take more informed business decisions. I do not doubt there are individuals with great gut-driven decision-making skills, but by and large, it's better if you look at data to make decisions. That's why you need a Data Lake. It could be a really small lake, it could be a pond or a puddle. But you need it for better decision making. Data Lakes, Big Data and other buzzwords Let's clear the air on a couple of misconceptions. The terms "Big Data" and "Data Lake" absolutely scream of corporate, of enterprise, of governance, compliance, r ## Vue.js Advanced Reactivity API and Caching Method-style Getters DevFeed: [Vue.js Advanced Reactivity API and Caching Method-style Getters]() Original publisher: [Read original article]() Author: Michael Gallagher Published: 2019-07-11T11:48:14Z Content type: tutorial Language: en Sources: [Teamwork]() Topics: [Caching](), [Vue.js](), [reactive](), [Code]() Tags: [advanced](), [caching](), [code](), [front-end-development](), [javascript](), [js](), [performance](), [vue](), [vue-js](), [vuejs](), [vuex]() ### AI overview This tutorial explains why Vuex method-style getter invocations do not cache their returned values, distinguishes that behavior from property-style getter caching, and discusses how to implement result caching when performance measurements justify it. It also relates the approach to Vue's Advanced Reactivity API and method-style computed properties. ### Source excerpt We're going to talk about a common request when working with relational data in Vuex. Why and how to cache method-style getter invocations, though the principles would also apply to method-style computed properties. If you have been following recent Vue v3 RFCs, you might have come across the Advanced Reactivity API, which comes as a very welcome direction for Vue to take. This article is written using Vue v2, but ultimately the code will be simplified if this RFC is implemented. Firstly, although both property-style and method-style getters offer caching as part of core Vuex functionality, method-style getter invocations do not cache results. If that doesn't make much sense, keep reading, it should become clear. What is a Method-style Getter? Below is the example from the Vuex documentation of a method-style getter, sometimes referred to as a parameterized getter. getTodoById: (state) => (id) => { return state.todos.find(todo => todo.id === id) } Normally a getter works by processing state into a given result. todoCount: (state) => state.todos.length, This will mean that store.getters.todoCount might provide the value 12, which will be cached in the event that the value is accessed again without any underlying reactive data changing. isTodoOpen: (state) => (id) => !!state.todos[id].assignee && state.todos[id].status !== 'complete', The above example can be accessed by store.getters.isTodoOpen(123) which will return a boolean. This value is not cached, calling it repeatedly will result in multiple executions. So what is cached here? Nothing from a reactive standpoint. When the getter property is accessed on the store, store.getters.isTodoOpen, just prior to invocation, this will run the outer function which will not access any reactive data, but create a function, an arrow which accepts id. This created function is now cached. Why aren't the results of these getters cached? There are lots of good reasons not to cache the results of these functions. How many times wo ## Embedding Teamwork Chat DevFeed: [Embedding Teamwork Chat]() Original publisher: [Read original article]() Author: Dawid Myslak Published: 2017-10-23T15:52:56Z Content type: article Language: en Sources: [Teamwork]() Topics: [Vue.js](), [Front end](), [JavaScript](), [Web Development](), [Webpack](), [Development](), [Framework](), [Library](), [flux](), [ESLint](), [Node.js]() Tags: [chat](), [development](), [eslint](), [flux](), [implementation](), [javascript](), [vuejs](), [vuex](), [webpack]() ### AI overview The article describes how Teamwork.com embedded Teamwork Chat Project Rooms directly in Teamwork Projects. The team chose a new component-based implementation and used Vue.js, Vuex, Webpack, modern JavaScript, ESLint, and reusable Node.js modules while considering performance. ### Source excerpt A couple of weeks ago we introduced a new feature in Teamwork Chat called Project Rooms. Project Rooms are a great way to create dedicated real-time communication channels for specific projects. Our next priority was to take this feature even further. Project Rooms in Teamwork Chat.Embedded Teamwork Chat Currently Project Rooms can be used inside Teamwork Chat, but our goal was to make them accessible directly in Teamwork Projects. To achieve this, we considered the following two options: Decouple only the important bits and pieces from the existing codebase of Teamwork Chat and deliver them as a standalone module. Create a brand new solution that follows component based architecture which could potentially be the future core codebase for the next generation of Teamwork Chat. After looking into this for a while, we decided that the second option will let us deliver a better quality solution. Our main concern with decoupling the existing codebase was the fact that we didn't use a component based architecture in the existing client. Unfortunately at the time of the initial implementation of the app, Knockout.js components weren't a common choice. New tech stack Earlier this year at Teamwork.com we made the decision that all our development teams will start using Vue.js as the main front-end framework. We also started working on creating a new internal build system based on Webpack, which allows us to use the latest front-end tools and makes the development process significantly more productive. Together with Vue.js we started using Vuex, which is a state management library inspired by Flux architecture. Another big change for us was dropping CoffeeScript and replacing it with the next generation of JavaScript. JavaScript ES2015+ comes with great new features and syntax, but also offers incredible editor support and great ESLint that makes our code more consistent across the team. New technology stack for embedded Teamwork Chat. Luckily, during the development of an ex ## Monolith to Microservice: Architecture Behind V2 Webhooks DevFeed: [Monolith to Microservice: Architecture Behind V2 Webhooks]() Original publisher: [Read original article]() Author: Paulius Jakimavičius Published: 2017-09-11T15:09:33Z Content type: article Language: en Sources: [Teamwork]() Topics: [Microservice](), [Architecture & Design](), [Go Language](), [HTTP](), [JSON](), [XML](), [JavaScript](), [callback]() Tags: [api](), [architecture](), [go](), [http](), [javascript](), [json](), [microservice-architecture](), [sha256](), [teamwork](), [teamwork-project](), [webhooks](), [xml]() ### AI overview This article explains the redesign of Teamwork Projects webhooks from a monolithic implementation to a Go microservice. The update supports multiple webhooks per event, sends complete datasets in JSON, XML, or form format, adds SHA-256 checksums, and uses more frequent retry intervals. ### Source excerpt We've recently released an update to the Teamwork Projects webhooks feature and I was asked to do a tech talk on the topic, a recording of which can be found below. This article is a rough summary of the talk with further elaboration of the thought process behind some of our decisions, but in summary: We have a microservice written in Go. We now support multiple webhooks per-event We send full datasets in chosen format (JSON, XML or Form) We offer better security and integrity with sha256 checksums We have more frequent retry intervals. https://medium.com/media/1208334bf98663ab7d55e4d2eaad4c95/hrefWhat are Webhooks? The basic idea of webhooks is simple -- it's a HTTP POST call triggered when some event occurs. You can think of it like a JavaScript callback, except it's a HTTP POST that can be sent anywhere, to anyone -- not limited to a single codebase or domain. In the case of Teamwork Projects, we have a set list of possible events you can subscribe to, denoted in OBJECT.ACTION style, so for example TASK.CREATED or MESSAGE.DELETED. Previous Approach (v1) Our original approach was no more complicated than the concept of webhooks itself -- when any of the supported actions are taken in Projects, a "fireWebhook" function is called, which checks if they're enabled and if there is a webhook set up for that event. If all is good -- we make a cfhttp call to the relevant URL with the item ID, item type and the action taken, all encoded as form data. Now there are a few limitations with this approach which showed up as the number of webhook users increased over time: Only one webhook per event -- although it made sense as a sort of anti-spam measure initially, this resulted in a few inconveniences for our customers. For example, a user sets up a TASK.CREATED webhook that notifies a custom service which adds the task ID to their internal database. This would make it impossible for them to later set up, say a Zapier zap using TASK.CREATED event as it is already "in use". Limited ## Teamwork Catalyst: A SaaS Incubator for Early-Stage Startups DevFeed: [Teamwork Catalyst: A SaaS Incubator for Early-Stage Startups]() Original publisher: [Read original article]() Author: Teamwork Engineering Published: 2017-02-13T14:07:14Z Content type: article Language: en Sources: [Teamwork]() Topics: [Software as a service](), [Software](), [Back end](), [Front end](), [web design](), [User experience (UX)]() Tags: [back-end](), [community](), [developers](), [front-end](), [mentorship](), [saas](), [startup](), [support](), [wi-fi]() ### AI overview Teamwork.com introduces Teamwork Catalyst, a SaaS incubator that offers early-stage startups free office space, Wi-Fi, refreshments, and monthly mentorship from its founders. The article also introduces several participating companies and their products. ### Source excerpt You may have heard our big news! We recently moved into some new digs! We've got big plans for Teamwork.com and big plans require lots of people to make them happen. In time we'll need more space, but it'll be a while before we're calling the slide manufacturers again. We like to be prepared though, so we held onto our old office space and have decided to put it to good use! We'd like to take this opportunity to tell you about our new little venture called Teamwork Catalyst -- a SaaS incubator for early-stage startups. We want to encourage businesses to grow, so we're offering this unused office space to SaaS startups. This means that they will have access to an office with free rent,Wi-Fi, coffee and snacks. Not only that, but Peter and Daniel, the two founders of Teamwork.com, will meet with the businesses in the incubator once a month and offer mentorship if needed. There is no catch. All that we ask is that you do your best work and get your business of the ground. Move In, Get to Work! This initiative started for a number of reasons. First of all, we know the pressures of being early stage startup, and it's no joke! We worked double-time to keep food on the table while we pursued our dream. We're hoping that with a little support with business mentoring and basic overhead costs, other entrepreneurs can avoid the same trap. Secondly, we want to encourage people to start their own business. Cork is a great place to have a start-up, and we want to help the burgeoning tech community thrive here. Since we had some office space empty anyway, this felt like the right thing to do. We've had great interest, and we've already have some very promising companies using the space. We can't wait to see them flourish. Here's a proper introduction: Backify: Back-end service for developers to enable people to build their MVP faster. Only front-end code must be developed, back-end is supported by Backify. Gymix: Creating music playlists for gyms, integrating sales commercials to p ## Is Teamwork.com the best place for developers to work in Ireland? DevFeed: [Is Teamwork.com the best place for developers to work in Ireland?]() Original publisher: [Read original article]() Author: Teamwork Engineering Published: 2017-02-07T15:48:40Z Content type: opinion Language: en Sources: [Teamwork]() Topics: [Learning](), [Hackathon]() Tags: [company](), [developers](), [hackathon](), [learning](), [work]() ### AI overview Teamwork.com describes why it believes its new Cork headquarters is a strong workplace for developers. The article highlights autonomy, reduced bureaucracy, employee ideas and hackathons, learning, shared technical knowledge, and regular demonstrations of work in production. ### Source excerpt We feel that Teamwork.com's new HQ in Cork just might be the best place for developers to work in Ireland because we -- Dan and I, the founders are developers ourselves and we're trying hard to create the perfect environment for developers to do their best work in a company and setting they love. Here are some of the reasons we think developers will love it here. 1. Your happiness matters to us We've learned that beyond a good salary the key for staff to be happy, they need 3 things -- Autonomy, Mastery and Purpose. We think about all 3 and do the following: Autonomy We try hard to minimise bureaucracy by keeping the company hierarchy fairly flat and having small autonomous teams for all products with sub-teams as needed. We don't want to slow our developers down so work hard to eliminate inefficient processes. Ever heard of the concept of "Minimum Viable Bureaucracy"? It's all about cutting down on politics and stuffiness and continuous improvement for reaching your goals in the best efficient way, that's exactly what we want at Teamwork.com. We are aware that "Good ideas can come from anywhere" -- we listen to feedback and suggestions from everywhere -- it doesn't matter if you're an intern and have just joined us, bring it on! Or showcase your great ideas at one of our Teamwork.com Hackathons. To give you an example, our product lead Conor had a terrific idea of letting users manage their workload and workflows in a better and faster way. His idea won our last Hackathon -- and as soon as we recovered from the 24-hour event, we rolled up our sleeves and got to work. A short while after, the Teamwork Project Summary was implemented. Mastery We want our developers to be the best developers they can be. Working in a strong learning community along talented developers, sharing ideas and using a tech stack that makes the most sense, ensures that skills are kept sharp and relevant. Learning never stops, that's why we give every new staff member a set of 13 books we believe e