We're playing with Google Data Studio, which has Google Spreadsheets and BigQuery support. How does this differ, assuming these integrations will be supported in the future?
Tech stack: Backend: nginx, puppet, capistrano, Ruby (Sinatra and RoR), Clojure, MySQL
Frontend: Responsive HTML5, JS / CoffeeScript, HAML, SASS with Compass and our internal framework
------------
About us:
* Regular dev catchups across all teams / show & tell to share experience
* We host / sponsor / attend hackathons and conferences
* We maintain healthy work/life balance - no extra long hours, weekends are for you to relax after a Friday beer in
the office / local pub
* We deploy to production multiple times a day
* We'll give you the tools you need to do your job (Macbook or other machine of your choice, whatever software you
need) and help you progress (budget for conferences, books and time to learn new tech)
* Flexibility in the tech choice
------------
About you:
* Able to own a problem and work with others (in your team and others in the business) towards a solution
* You're open-minded and flexible - you can pick up new skills / languages
* You can work well in a team environment (occasional remote work is ok, but we're mostly in the office)
* Comfortable with basic devops tasks
* Skilled at table tennis or table football (optional)
------------
Next steps:
Contact me directly - [email protected] - I'm a developer in one of the teams you could be joining. Tell me about yourself (whatever you think represents you best) and ideally let's meet up - will give you a tour of our new London Bridge office and talk about the projects we've been working on.
As part of our recruitment process, you'll have to complete a coding exercise and later come for face to face interviews.
Tech stack:
Backend: nginx, puppet, capistrano, Ruby (Sinatra and RoR), Clojure, MySQL
Frontend: Responsive HTML5, JS / CoffeeScript, HAML, SASS with Compass and our internal framework
------------
About us:
* Regular dev catchups across all teams / show & tell to share experience
* We host / sponsor / attend hackathons and conferences
* We maintain healthy work/life balance - no extra long hours, weekends are for you to relax after a Friday beer in the office / local pub
* We deploy to production multiple times a day
* We'll give you the tools you need to do your job (Macbook or other machine of your choice, whatever software you need) and help you progress (budget for conferences, books and time to learn new tech)
* Flexibility in the tech choice
------------
About you:
* Able to own a problem and work with others (in your team and others in the business) towards a solution
* You're open-minded and flexible - you can pick up new skills / languages
* You can work well in a team environment (occasional remote work is ok, but we're mostly in the office)
* Comfortable with basic devops tasks
* Skilled at table tennis or table football (optional)
------------
Next steps:
Contact me directly - [email protected] - I'm a developer in one of the teams you could be joining. Tell me about yourself (whatever you think represents you best) and ideally let's meet up - will give you a tour of our new London Bridge office and talk about the projects we've been working on.
As part of our recruitment process, you'll have to complete a coding exercise and later come for face to face interviews.
Microservices here are mostly fancy word for an API or an app consuming API or listening for events. At least in my department, we have a fair amount of legacy code, coupled together, as the application and CMS grew over the years; we're now working on splitting things up, e.g. reports don't need to be part of the same code as CMS. Scheduled jobs for grabbing 3rd party feeds can be separated into its own app. Any significant part of the system is eventually going to be living on its own - so that deploying one part shouldn't break others; running a bad query on our reporting DB will not affect production DB etc.
I guess the downside of this approach is having to manage overhead of each of these services (setting up puppet, nginx, caching etc.); majority of our apps live in a shared puppet config so it's not too difficult to spin up a new box in EC2 and apply puppet to it, but also as you grow bigger you might want to split out these configurations (different teams = different needs) or have a curated/moderated central configuration (that's sort of the way we have it now).
Regarding communication between services, not sure exactly what you mean, usually when we split something out of existing system, the legacy code just makes a call to this new external service to get the data.
Regarding Developer Anarchy.. no of course we're not just developers :) Each dev team works with designers, marketing and commercial people. Priorities/objectives come from business people and we just help them figure out how to reach their goals and inform them on possibilities from technical side. Day to day however, we're mostly left to our own, so it's pretty great. We don't have project managers in a typical sense, we decide our timelines and tools.
I haven't seen that video yet, it's also before my time here (I've been here 1.5 year), but either way it's very developer friendly environment with plenty of freedom.
Ping me on Skype (tomasz-tomczyk) or email if you'd like to know anything more.
I don't think Developer Anarchy is tied to idea of micro services? We empower developers to write code and deploy it to production daily to avoid any bottlenecks to do with management; we write microservices where it makes sense to decouple systems and make them into reusable services.
* regular dev catchups across all teams / show & tell to share experience
* we host / sponsor / attend hackathons and conferences
* we maintain healthy work/life balance - no extra long hours, weekends are for you to relax after a beer on a Friday in the office / local pub
* we deploy to production multiple times a day
* we'll give you the tools you need to do your job (Macbook or other machine of your choice, whatever software you need) and help you progress (budget for conferences, books and time to learn new tech)
------------
About you:
* able to own a problem and work with others towards a solution
* you're open minded and flexible - you can pick up new skills / languages
* you can work well in a team environment (occasional remote work is ok, but we're mostly in the office)
* skilled at table tennis or table football (optional)
* comfortable in *nix
------------
Next steps:
Contact me directly - [email protected] - I'm a developer in one of the teams you could be joining, tell me about yourself (whatever you think represents you best) and ideally let's meet up - will give you a tour of our new London Bridge office and talk about the projects we've been working on.
1) Totally self taught. When I first got online, I thought the concept of websites was really cool, viewed the source of the first page I knew existed (from an ad in magazine!), copied it and edited. There was only one HTML course worth reading at the time in my language and that's what got me started. Then another developer on IRC told me about PHP, then got into server administration and so on. By the time I got to uni I had some small commercial projects under my belt; University wasn't helpful, as most of the stuff we were taught was outdated, but I did learn to work in groups better.
Most of my basic programming knowledge came from PHP manual and the comments within.
Since then, a lot of my knowledge just comes from experience.. you learn by doing, something has gone wrong - Google it. Now that I'm working, when I'm desperate, I have peers to bother too, but prefer working it out myself.
2) 1999 at the age of 12 - that was just HTML/CSS at the time, got into PHP within a year or so, then more advanced JS / node.js / Ruby in the last 3 years of working professionally.
3) Got my first job not long after finishing University - 2010
I'm using Sinatra - little overhead, simple code.
I used node.js/express.js in the past, but the callback hell made me dislike it a bit, although admittedly I'm not experienced with node, so there might be a way to avoid that.
I had a look at Firebase and my main problem with it is having to rely on 3rd party service and storing data on their servers + portability if I was to decide to leave them in the future.
I'm gonna try and come up with a way to integrate markdown files into http://mixture.io/ - just discovered this today and I'm determined to try it out, but I do need markdown files for content.