codebar

2015, a sensational year for us here at codebar, has reached its end. Throughout this time we opened a number of new chapters, ran many great events, grew our community by almost 120% and facilitated over 100 workshops across 8 of our chapters. We had an amazing time meeting all of you and building up our amazing community. Let’s take a closer look at our achievements this year.

On top of our regular workshops, we also ran some great events:

• Kickstart Your Developer Career
• Mind the Code
• uncodebar
• 24 Pull Requests 2015
• Code and Chips - Building an RFID and QR code scavenger hunt

And we took part in some amazing initiatives:

Salzburg and the Sound of Music are traditionally inseparable, but there was little traditional about the sound of music in the Salzburg Congress hall in the middle of October.

Joseph Wilk (@josephwilk) was one of the presenters at EuRuKo 2015. He gave a talk and demo turning Ruby coding skills into a live performance.

What’s new and exciting about making music from code, Joseph said, is that it doesn’t matter that he’s making code. He’s simply making music.

Getting away from the traditionalist view of coding as something exclusive for certain types of programmers, is very exciting for him about coding today.

“We’re reaching a point where people are starting to not accept how they’re told to use code. People are starting to say: let me discover for myself how I want to use it.”

“And that brings wonderful new things together in new ways, like weaving and coding and design and coding. People are starting to break apart the technology and designing for themselves from scratch.”

Some of these new things are what Dot, from codebar Brighton, liked best about the conference.

“You come to get an in-depth understanding of what’s involved in some aspects of the code.” she said. “But also to get different ideas. I’d never thought to make a game in Ruby.”

“It was interesting to see Ruby in the GUI since we often tend to think of Ruby as a language that is only useful for writing web backends.”

“When you’re writing Ruby in the day-to-day work environment there are many things you don’t think about, the conference shows you some of the fun things going on and some of the more obscure things.”

Those obscure things included 64bites.com founder Michał Taszycki (@mehowte) show the audience how to program a Commodore 64 and Amy Wibowo (@sailorhg) demonstrate an exploration of origami’s cut and fold problem.

People of all ages and from countries all over the world came together under the umbrella of a common language in Ruby.

A language that allows people to think up an idea, work out how things need to be, and then make it into a working prototype or even program.

Dot, Foirell, Kriszta, Jen, and Sally from our codebar communities in London and Brighton went to the conference thanks to amazing London sponsor, @shutl!

The keynote speaker was none other than Yukihiro ‘Matz’ Matsumoto, the chief designer and mastermind behind Ruby.

He kicked off the conference with a visionary look at the interesting new stuff that the Ruby Core team is planning to add to Ruby, told through the humour of a Japanese language lesson. To the attendees relief, he also promised compatibility with Ruby 2.0.

Some of the more scientific and challenging talks were less Ruby specific: Bradley Grzesiak (@listrophy) spoke about simplifying challenging software problems with rocket science, while Satoshi Tagomori addressed a data analytics service and its Ruby usage.

Some combined both. Hanneli Tavante (@hannelita) spoke on Humanising Math and Physics on Computer Science. She said Ruby was her first language of choice because,

“We see Ruby for DevOps such as automated scripts, or a simple parser, but it can fit most scenarios, and it’s usage depends on what kind of performance you need and requirements.”

“It’s easy for me to think in Ruby, but I think in Ruby and then if I need to for example, translate into Python. The syntax I find really pleasant too.”

“The language itself is very easy to write and it has some very interesting features. Ruby is good for beginners, and for senior developers.”

“What’s new and exciting is also the development of the language towards new languages we have, such as Elixir, or Rust.”

A more fun and personal highlight was the demo by Amy Wibowo – Fold, paper, scissors – an exploration of origami’s cut and fold problem.

The fold and cut theorem states that it is possible, given a piece of paper and any polygonal shape, to find a series of folds of that paper such that the given shape can be generated with a single cut.

Her talk explored a Ruby implementation of a solver that determined the correct series of folds given any input polygon.

What were some of the other take-aways?

René Föhring has created a tool called Inch, an inline documentation quality check, to get people excited about inline docs. Shoes for cross-platform GUI, Sonic Pi for music composition, RbNaCl for cryptography.

In addition to the learnings, the Ruby community clearly also had a great time together over two days, and at the spirited Saturday night after-party.

That spirit is one reason to join a conference but also to join a community or club all year round.

Lisa Passing, Tam Eastleigh and Sarah Regan formed the rubycorns in Berlin in 2013, a project group for Ruby beginners to learn and work on an app together.

“One of the challenges of learning Ruby is keeping motivated, it’s hard to know how to do that as a beginner. The community is great. People are kind and welcoming and excited to teach me.”

And if she was starting out, I asked Lisa. What would she start with?

“Start with a project like an app that you love to use, and build a clone of it. For us it was creating a list of support groups. Then figure out what you want to do. Figuring that out might be for fun or it might be your way of earning a living.”

Typically Ruby is not as popular as other languages. While there are Ruby jobs out there, there are many more PHP and Java jobs but to Kevin McPhillips, Developer Team Lead at shopify, the language you use is less important than being excellent.

The event’s key sponsor told the audience that the market is massive and that attendees had, for example, probably used a Shopify store but not seen it behind the scenes:

“Our core application is written on Ruby on Rails but we have a huge technology stack. Java, Python for the data science team, Go for some of our more concurrent tools.”

“The company is hiring. We’re looking for people not specialists. I can teach someone a tool, we can teach excellent people anything.”

Be excellent. As coders, as communicators, and as a community, that was a theme that hit all the right notes. Perhaps the best take away of all.

Check out the speakers’ decks here: http://eventifier.com/event/euruko2015/slides

In the days leading up to our 24 Pull Requests event, we asked the community to submit good, beginner-friendly issues they found on Github for our students to work on during the event. Our 24 Pull Requests themed event is a day of helping beginner coders get started in contributing to open source software. The most common question we got was what constitutes a good beginner open source issue? The question is valid, especially from the perspective of a seasoned developer who can make sense of very specific jargon and can understand other developers’ intentions from a few brief sentences. That isn’t the case for a complete beginner. As someone who was once a beginner - some would say still is - I think I can give some tips on what kind of issues helped me get started with open source and what kind of issues might suit other beginners.

Small bugs, or very small features

As a beginner it is important to start with small, succinct tasks. Things that can be solved in a day or better, an hour. Remember, when you are a beginner, contributing to open source isn’t only about fixing the bug but everything else that comes with the process: forking the repo, cloning it, setting it up, finding the bug, fixing it, adding, committing, pushing, opening the PR and so on. This might mean relinquishing some control of your project and offering up quick fixes and small features to potential contributors. Yes, you might be able to fix that small bug in two seconds yourself and never think about it again, but for a beginner that two second bug might be the issue that sets them off on a journey of contributing to open source.

Issues with a clear context

We’ve all seen issues on Github with a non-descriptive title like ‘remove no-js tags with js’. No description, no context. This in principal sounds like something a beginner with very little Javascript knowledge could do. Right. Detect whether an element has a no-js class and consequently remove it. But the lack of context makes it almost impossible to understand what the actual issue is and what is expected of the contributor. A good beginner issue has a clear description and gives as much guidance as possible without actually solving the issue. You are a project maintainer and might have an idea where in the project the bug might lie? Good, include the partial you think the bug might be coming from. You have a visual representation of the issue? Great, include a screenshot of it. The more details you include the better.

Projects with a setup guide

Not once have I found an issue on Github I deemed solvable with my limited skills only to find out the project has no setup instructions. As I mentioned in the first point, setting up the project itself is one of the most daunting parts of starting to contribute to open source. I have personally abandoned several projects because I got stuck whilst setting up the local dev environment and found the effort of reaching out to the maintainer or figuring it out on my own too much compared to the relatively easy task of solving a simple issue. If you want people to contribute to your project please take the time to write clear and detailed setup instructions.

Responsive project maintainers

It can be extremely discouraging to finally open that first PR you’ve worked so hard on, to then not hear from the maintainer for weeks, sometimes even months. We at codebar are guilty of this too. It is hard to always be up to date on a project from a maintainers point of view, but it is extremely important for a beginner to get prompt feedback on their PR. Don’t be afraid to give feedback either. If you don’t like the design they did for example, or want them to refactor some code, let them know in a respectful and objective way. The key is clear and respectful communication and collaboration.

It’s not only about code

This has been said many times but code is not the only way to contribute to an open source project. Think about all the other components that make up a project: documentation, visual design, UX, user testing, accessibility, etc. These are all components of your project that you can open up to the community. But don’t over do it either. I’ve seen many, many issues that simply stated ‘write documentation for xy’. How would a beginner, who relies on documentation more than anything, know where to start with it? Provide a rough draft of the documentation and ask people to contribute to that.

Conclusion

All of this means that project maintainers have to put in the time to create issues that are clear and understandable. It means they have to aid and help out beginners to contribute to open source projects. This may mean holding someone’s hand in fixing their first issue and submitting their first PR on the project. Yes, this takes time and effort, but it’s the only way to build a community of willing participants around a project and to get more people involved in open source.

Here at codebar we run over a hundred workshops a year for people underrepresented in the tech industry - 52 in our Central London chapter alone. All this is possible thanks to our dedicated coaches who volunteer their free time to come and teach our students week after week. While codebar is all about the students, we wanted to acknowledge the hard work our coaches put into codebar to make it as successful as it is.

With this in mind we devised uncodebar, the codebar unconference. We wanted to run an event that focused on our coaches, a platform for them to come together and share knowledge with each other. We wanted this event to be an informal, casual space that encouraged collaboration between coaches and strengthened the already vibrant community we built in the two years of codebar’s existence.

So on the 10th of October 2015 we all gathered in the GoCardless offices in London for a day of talks and workshops, all given by our coaches. For those not familiar with the format, an unconference is a participant driven event, a loosely structured conference emphasizing the informal exchange of information and ideas between participants. At an unconference, the schedule is open ended and is put together on the day by the participants, who fill in the spots with talks or workshops they have prepared for the event.

We were floored by the eagerness of the attendees to contribute to the event and by the kind way everyone treated each other. We had an amazing array of talks, with topics ranging from Data Visualization with D3.js, Intro to Docker, Regular Expressions for the Strong of Heart, BEM and SMACCS, Behavioral Economics for Developers to Introduction to Property Based Testing in Haskell. We participated in a Failure Swapshop and had a fun Arduino session making LED’s blink. We had plenty of breaks where attendees could break out into smaller groups and get to know each other better. We had amazing food and plenty of beers to keep the conversation flowing. We finished the day with a quick round of lightning talks that included a groundbreaking talk on Taylor Swift Driven Development by our very own Denise.

We were exceedingly happy that the attendees had the same impression of the day as we did. We received nothing but positive feedback, this quite from @ThisIsJoFrank particularly explains well why we think the event was a succes:

Every talk that I went to was interesting, engaging and well presented. The coaches are a talented lot, the wealth of information shared was proof of that, but it wasn’t just shared knowledge, it was the encouragement and enthusiasm that everyone brought to the day and the feeling of positivity and mutual respect that really made uncodebar stand out from other conferences that I’ve attended.

Of course none of this could’ve happened without the support of our sponsors. Thanks to 8th Light, Codurance, and Crowdmix for their generous donations and GoCardless for hosting us in their offices.

All in all we had an amazing day filled with inspiring workshops, talks, conversation and good food. The event had a great energy and we walked away after the day feeling inspired to continue our work with codebar and thankful to be part of such an inspiring community of technologists.

codebar is a non-profit initiative that facilitates the growth of a diverse tech community. We run regular programming workshops for women, LGBTQ and people from underrepresented minority groups. Our goal is to enable our students to learn programming in a safe and collaborative environment and expand their career opportunities.

codebar sessions run for 2 hours, in which students can choose to follow either our set tutorials or focus on a personal project. We take pride in offering a 2:1 student to coach ratio so students get the attention they deserve.

Predominantly our sessions run across the UK but more recently we have expanded to Brazil, America and now… Bournemouth!

Bournemouth has a vibrant tech scene which is growing rapidly - it has an estimated 450 creative agencies in the area and is home to the world’s largest Open Device Lab. It is also host to over 100 events a year; including meet-ups, hack days, unconferences and full blown conferences. Oh, and did I mention that the beach was voted the best beach in the UK and fourth best in Europe:

Now our request to you. codebar’s mission is to teach programming but for this to happen we need your help. Yes you reading this blog post. We need your help spreading the codebar mission, help getting coaches on board and help getting people involved who want to learn to code. We also need sponsors, as without them codebar would not be possible. They provide us with space, food, drinks and of course internet. So, if you work somewhere that could host a codebar then please contact us, hello@codebar.io or @codebarBmth.

Get involved

Our first workshop will be held on Tuesday 13th October at Folk from 6:30pm. If you want to attend this workshop as a coach or a student you must sign up via the website, equally if you know someone who is interested in coding and fits our eligibilty criteria get them to sign up too. Or if you want to help us by becoming a host for this chapter then please email us at hello@codebar.io.

P.S Thank you Matt Northam for the incredible picture of the beach.

Thanks to your enthusiasm, codebar London has expanded rapidly in the past couple of months. I’m sure you have noticed the waiting list getting longer every week and the number of attendees per event rising steadily lately. Not only that, London is a massive city with students and coaches living scattered around it’s area, with some people having to travel up to an hour to attend certain workshops. This obviously is not an ideal situation as we want our workshops to be easily accessible by the most number of students, with a number of attendees at each workshop that is still manageable by us (the organisers) and is not a hindrance to learning (taking too long to organiser ourselves, etc…).

To combat this situation we have started running events in South London, on top of the original Central London location and now we are adding West London to the roster. The Central and South London workshops will both be held on Wednesdays, while the West London workshop will be offered on Tuesdays. The first West London workshop will be held on the 14th of July, 2015.

A quick note about the different London chapters: you are more than welcome to sign up to all three of them and attend whichever workshop is most convenient for you that week. But please do not double book yourself on workshops (especially in the case of the Central and South London workshops which run on the same day). We do not have time to go through names and remove you from a list. Please bare this in mind when confirming your attendance for a workshop. Please also be respectful of other students: if you can no longer attend a workshop cancel your attendance through the site so someone else can take your place. Hopefully the increased number of workshops will allow more of you to dip your toes into programming and take part in the codebar experience.

On another note we have been nominated for the Grassroots Event of the Year award at the net awards. This is an amazing achievement for us as it is nominated by you. So if you have a spare 10 seconds please vote for us.

Friday 19th June was a brilliant day, partly because of the glorious sunshine and partly because 12 codebar Brighton students spent the day at the 3rd and final Responsive Day Out ‘The Final Breakpoint’ thanks to ticket giveaways from the lovely people at Clearleft.

What is Responsive Day Out?

Responsive Day Out is a day conference comprised of topics branching responsive web design. It gathers designers and developers sharing their workflow strategies, techniques, and experiences with responsive web design.

What is Responsive Web Design?

Responsive web design is the practice of building a website suitable to work on every device and every screen size, no matter how large or small, mobile or desktop.

Building responsive websites primarily requires the use of HTML, CSS and possibly Javascript skills. This resonated well with the codebar students that attended as they have been building on these skills at codebar. The codebar tutorials don’t yet progress onto building responsive sites so this really got everyone thinking about how they could extend their current skill sets to encompass these ideas. It was also a real eye opener in to just how much there is to think about when designing for cross browser and cross platform.

The Day!

The conference was held at the Brighton Dome Corn Exchange, anyone who has been to Brighton will know that this is a beautiful building, well located between lots of nice places to eat and drink. The staff were friendly and helpful and the breaks made for a great opportunity to get to know some of the other attendees.

There were 12 talks, all of which were engaging and of high quality. Talks were grouped in 3s (around 20 minutes each) followed by a quick chat between conference host Jeremy Keith and those speakers before breaks for sun and coffee.

The Speakers

As codebar is an event aimed at encouraging diversity in tech we were pleased that there were so many inspiring female speakers on the bill. To us it signifies women holding strong presence in this industry. It is encouraging for other women either starting out or further into careers, when it is actively projected that women should be present, seen, heard and their knowledge shared.

The audio recordings are already available on the Responsive Day Out 3 Page but here is a quick overview of a few of the talks:

Alice Bartlett -

Alice is a front end developer at GDS and her talk title was ‘What is the business case of accessibility?’ She opened the conference, creating a great atmosphere as her speaking style came across very confident and naturally funny. She spoke about the alpha and beta stages of the GDS site and the process of making the site accessible. Ideas were developed with an objective: Not to frame what people may lack but instead to design in terms of what they (GDS) should provide. Through her experiences and through writing this talk, Alice found that accessibility is not the easiest businesses case to make but morally we should never need a business case for it. She recommended quick ways to improve accessibility to a site are running a screen reader over it and adding Aria. She also recommended joining discussions on the GDS Hack Pad where design ideas are shared.

Rachel Shillcock -

Rachel is self employed, often designing for entrepreneurs with a focus on female entrepreneurs. She spoke about accessibility and how it isn’t something that can be tagged on at the end - no body should be left behind. She shared useful tools for making a site more accessible which will be especially useful for codebar students looking to make improvements in that area. These tools included Contrast Ratio an online colour contrast checker that gives an A, AA or AAA accessibility rating for a colour against a background colour. Another was tota11y which lets you add a checklist to your page which will rate and advise your pages’ accessibility. Plenty of advice can also be found on a11yproject. She concluded that ultimately testing on real life people will help you achieve the best results.

Alla Kholmatova -

Alla is an interaction designer at FutureLearn. She spoke about taking a modular approach to design. She had found that a lack of shared language had hindered the original design process. They focused on perfecting the language used when naming components. A key takeaway was about how it was much harder to design ‘a kit’ than it was to design a whole page but the results were worthwhile. Another interesting part of their design process was that they actually handed away control from solely the designers and involved team members across disciplines. When working with users they worked with paper cards displaying the components which gave a more tangible and creative experience.

Jake Archibald -

Jake spoke about Modern Progressive Enhancement. Jake began by talking about performance and how the part to focus on is the time between the 1st render and 1st interaction. He spoke about the frustration of ‘lie-fi’ aka when your phone is telling you that you are connected but in reality the page never loads. He introduced the Service Worker API and how this will open up possibilities to browse offline. He demonstrated an app that allowed the user to make Wikipedia pages available offline. The problem then occurred if the user wanted to click on a link from the offline page and were not connected. In this instance, Service Worker could ask if the user would like to be notified when the page is available to view and could then send a push notification when the user next become connected. This seems like it would be very useful… especially for train journeys.

Ruth John -

Ruth’s talk was brilliant as she had prepared lots of demonstrations for using different web APIs. These included the geolocations API, web animation API, web audio API, ambient light API and more. There is a Web Audio API book by Boris Smus available to read for free online which comes recommended. Hopefully this triggered a few project ideas for codebar students!

Rosie Campbell -

Rosie works as a Technologist at BBC Research and Development which we thought seemed like a very cool job to have. She spoke about a research project they had undertaken with smart electronic wallpaper. The idea is that this wallpaper covers the walls in your living room and then when you watch tv the wall paper can change to give more of an immersive viewing experience spilling beyond the boundaries of the TV. You could be watching Glastonbury and there could be festival maps or set times or maybe a ‘Blur’ wall if Blur were playing with artwork from the band, possibly a crowd wall too. If there was a build up to a TV show you liked, maybe the photo frames could be slowly filled with character images over the course of the build up. This seems would also be great for parties if music videos could be projected all around the room.

Rosie spoke about designing with constraints to breed creativity which is why they kept a TV in the design. We recommend you read more about the Unconventional Screens project here.

Lyza Danger Gardner -

Lyza was great to watch, very engaging and brilliant at telling the her story. She spoke about the conflicts she felt around being a generalist and working as a software engineer. When she discovered HTML in 1993 she felt huge excitement - that she could reach the world with some p tags on a page. She loved pursuits with tangible results and felt the web was a generalist paradise. The web took a big leap when CSS was introduced and over time she began to find the complexity of the web tiring.

Before the web, if you heard lyrics on the radio you couldn’t just google the song. You had to look up academic information in reference libraries, but now with the web we are the reference library. More and more new frameworks are released and it can lead to demotivation and feelings of incomplete mastery making it much harder to be a generalist.

Lyza mentioned that she loved the word ‘developer’ which is something that resonated with some of the codebar students, it is great to be able to develop and carry out ideas. She spoke about how it takes bravery to feel like a beginner again and again as changes happen in the web. It is comforting to know that everyone feels out of their depth at times when learning.

Conclusion

Responsive Day Out was a fabulous experience and we are slightly sad that this was the last one! Thank you very much to Clearleft and all the speakers. We came a way with a lot to think about and plenty of ideas to incorporate into our own projects.

On Saturday 4th June we organised Mind the Code, a day dedicated to mindfulness. Our aim was to run a slightly different event to anything we have ever ran before, where the day consisted of talks, workshops and yoga.

The day began with a few lightning talks from all of our sponsors and the first main talk of the day by Emily Atkinson, developer and product manager at Moo. Emily’s talk focused on coding mindfully. The first half of her talk focused on viewing code as a means to solving a problem. She discussed that as a developer you do not sit down to ‘write code’, you sit down to solve a problem. The second half of her talk was trying to get the audience to think about how other people view your code, and compared this to the foundations of a house. You want a solid base so that other developers can jump into the project and build upon your code without ruining your previous work.

The second part to the day was an exercise on domain modelling. Students and coaches were paired up randomly and asked to design a new system for managing the London Tube system. Using paper and pens, we asked them to think about the concepts behind this model, classes, and who would be responsible for these classes and the relationship between them.

Once the first half of the day was completed, the first Yoga session was taken by Sandrine. This was then followed by lunch, provided by Pronto.

Next began our main coding workshop. The task here was to pick one of our set projects and begin building it with their coaches. The projects included a yoga slot machine, yoga lullabies, yoga pose name generator, online mode ring and a to-do list. The aim of this workshop was to get the students started on a projects of their choice.

We then had a second yoga workshop, for those that did not do it the first time, followed by the afternoon session of lightning talks. The first lightning talk was by Kimberley Cook, codebar organiser and front-end/iOS developer at Pixeled Eggs, on motivation. The second lightning talk was by Ryan Hanna, mobile developer at Sworkit, on building hybrid apps with HMTL/CSS and JS. And the final talk was by Alex Peattie, CTO at Peg, on developing mindful code regardless of your level.

After the lightning talks we had the second part to the coding workshop, which was a continuation of the first workshop. We stressed that the projects did not need to be finished as the workshop was more about what it means to develop software, and to have fun building it too.

We want to say a huge thanks to all of our sponsors MailJet, Shutl, Twilio and Makers Academy. Also a huge thank you to Michela Tannoia for designing our stickers. Without all of your support the day would not have been possible. And a final big thank you to all the students and coaches who attended and made our first Mind the Code an absolute blast.

On Saturday April 18, Kriszta, Jarkyn, and Denise took part in London’s first-ever Clojurebridge workshop, hosted at uSwitch’s sunny offices in Southwark. We learned TONS of Clojure – our brains were mush by the end of the day! – and were able to experience how a workshop can successfully cater for many different experience levels. The students participating in the workshop came from all different backgrounds. Some were full-time developers looking to pick up some functional programming as a hobby; others were newcomers to coding altogether.

As newcomers to functional programming, we quickly realized that we would need to think about problem-solving in a completely different way if we were to become good Clojure developers. Unlike object-oriented languages such as Ruby or Javascript (most of the time..), functions are first-class citizens in Clojure – quite literally, because the function precedes each list. Because objects don’t exist in the same way as Ruby objects, they can’t hold state. As a result, data passed into a Clojure function is processed in a consistent, predictable way. Clojure can also developed with fast feedback cycles because it is richly supported by instant REPLs in several editors. An interesting side effect of this is that, while Test Driven Development (TDD) has many evangelists in Ruby and Java communities, TDD did not seem to have the same following in the Clojure community.

We worked our way through the Clojurebridge tutorials relatively quickly, then spent lots of time experimenting with our new skills. We wired together a basic web API and practiced making requests to some public APIs, which is where Clojure really steps up to bat. I was sold on Clojure when I saw how elegantly and efficiently you can traverse an HTTP response.

But, a blog post on Clojurebridge would be incomplete without a shoutout to the amount of hospitality we received! The organisers, sponsors, and hosts made sure there was no chance of us going hungry at any point. A constant stream of bagels, fruit, cheese, sandwiches, coffee, tea, and beer kept us caffeinated and energized. Codebar has to step up our game now… :)

For anyone interested in learning Clojure, there are a wealth of resources online. Here are a small handful of them:

• Clojurebridge Tutorials
• Clojure Koans
• 4Clojure
• Learn Clojure

For information on Clojurebridge London and their upcoming events, check out their official website. There is also a vibrant community of London Clojurians who hold weekly meetups in various formats.

Last Wednesday saw 24 students and 12 coaches attend the first ever South London Codebar at Pact Coffee HQ. The structure of the event was the same as normal, a lightning talk followed by a 2 hour workshop, this time just south of the River Thames.

The lightning talk was given by Tony To, tech lead at Pact Coffee, about… you guessed it Pact Coffee. He gave us an insight into what life is like at Pact and the journey the coffee goes through, from delivery to their HQ to distribution to customers. He also gave us a little introduction into the tech that Pact Coffee use to maintain their website and app, and how a Raspberry Pi powers their distribution printer.

Then as normal students and coaches were matched up for the 2 hour workshop.

We would like to thank Pact Coffee for donating their venue for this event. And another huge thank you to Hire Space for their generous donation towards this event.

Without the generous donations of both Pact and Hire Space this event would not have happened. If you are a company in South London and would like to sponsor an event, or donate your venue for the evening, then please get in contact at south-london@codebar.io