00:02:54.950
We will start with "Fun with Programming Spreadsheets." I'm not going to be doing that, but sorry, Thomas. So we have five minutes for each talk. We have a timer, and after the five minutes, we will be hitting the gun. This is mirrored pointer left-hand mic.
00:03:08.380
All right, hi, I'm Thomas. You're taking away precious time, I think. So, an excuse for the strike, but I can ask the sensor to advance to my slides. There's a strike-through. The original technique was fine with spreadsheets, but you know, there's no fun with spreadsheets. So we are talking about programming spreadsheets. But why spreadsheets? It's such a boring topic. We are all programmers too, and we hope that we are not going to have to interact with spreadsheets in our regular careers. That's the idea. But spreadsheets are basic tools for many professions.
00:03:32.940
There are many professionals working with spreadsheets on a daily basis. Your organization probably has one or many people who actually get things done with those spreadsheets, possibly the critical stuff that makes our salaries go through and keeps the business running. Basically, most SaaS startups first need to compete with Excel. They first need to compete with the spreadsheets that are being used by people in a specific profession to solve their specific business problems. But yeah, we still hate spreadsheets, right? I mean, even if we can program them a bit, this programming is still kind of limited—very convoluted and constrained. There's no Ruby, and there's not much programming craftsmanship that you can show while working with spreadsheets.
00:04:44.470
But spreadsheets are not in decline, unfortunately. They've been around for 30 years, and I think they're going to be around for a few decades more. So I think we need to live with them. But why should we care? Well, because spreadsheets are not boring. They could be. Due to advancements in recent years, we can actually make spreadsheets fun and do a lot more in an automated way that we are used to. For example, imagine if we had a spreadsheet where someone in our organization could do something, and the spreadsheet could talk with an API over HTTP, grabbing some JSON and displaying this data.
00:05:14.620
That would be, well, maybe not pretty cool. I mean, come on, it’s not cool to just consume an API endpoint. But still, it would allow this person to automatically get some data from other software that we use or the software that we provide, maybe. Ultimately, our work would have a specific, case-specific problem solved without having to build a whole application. So we could talk to internal APIs and also script the spreadsheets with JavaScript. I know JavaScript is a dirty word, and I haven’t served this out for my slides, which I’m really sorry about. I know we are at the Ruby conference.
00:06:14.980
I don't like JavaScript at all, but still, it’s our best bet if we want something resembling a modern programming language in our spreadsheet. Let’s see if we can do it. Actually, we can! This talk is focused on Google Spreadsheets, but I know that in Office 365 by Microsoft, there's also a JavaScript framework that we can use for programming. Okay, I'm two minutes until the end, that’s cool. I'm going to speak quicker and quicker as I see the counter timer.
00:06:52.240
We can browse the documentation and see that we have actually a whole API, which is even synchronous. So it's way better than what we are used to with JavaScript in terms of input and output: we can fetch data from external APIs. And you have a JSON parser. We can write a function that will just return an array of data and put it in our spreadsheet. We can write some simple JavaScript, for example, to fetch some code from an external API.
00:07:42.830
It's kind of complicated because it actually works, you know? There's authorization stuff, and then there's messaging this data because we need to take the JSON and put it into an array of arrays. If we run this stuff, it actually fetches data from the outside, massages it, and displays it on the spreadsheet. For example, our accountant suddenly does not have to export the data into CSV and copy everything over. They can just fetch it automatically from the outside Internet, and it works! This was an actual working code.
00:08:05.240
This is, of course, recorded video for the Lightning Talk; I'm not crazy enough for this. I just program spreadsheets, and there’s a lot more we can integrate with Google services. We can integrate with any database that talks over JDBC, which means any database, even the ones you don’t want to use. We can even send data away based on what’s in our spreadsheet. So just go ahead and enjoy! See if you can help the people in your organization use spreadsheets better without needing dedicated software.
00:08:38.990
That’s it! Thank you, I’m Thomas, and thank you very much. Next, Anna will present another way to stay tuned with Ruby. Good luck, Anna! You have five minutes.
00:09:24.950
Today I’m going to share my experience dealing with lots of subscriptions—Twitter accounts, Medium subscriptions, RSS, and so on. Everyone wants uninterrupted time. When we are busy, it’s not enough to do our daily job and then just call it a day. Everyone reads a lot and follows fresh news emerging every day. It takes a lot of effort to keep up and read everything on a daily basis.
00:09:55.590
Here are some examples of subscriptions I used to have: I used to use IFTTT to put everything into my Pocket account. It was actually a good application, but it didn’t work for me. For example, when I switched to Gmail, all the news that I subscribed to got fed into my Gmail account. If I was on a business trip and fell out of my daily schedule, I would forget about all the news I had to read. If I would have 30 notifications one day, it could be up to 150 when I returned, and if I had an application, it could be like 60 or more.
00:10:40.710
There were also other problems, like unused applications that were a bit demotivating. News can emerge at different times, and when you start reading, you realize you need some time before you catch up. Another problem for me was receiving media noise about certain topics. For instance, I know about Jacob, and I don’t want to read about him every week.
00:11:02.020
I decided to build my own bot that sends news to me every day in the morning, and I can read it. It has some benefits: it provides unique news, relevant information for me, and it is daily, so I don’t get distracted.
00:11:13.270
If you are using Telegram, you can try this QR code. You can take a picture and open it. I hope my bot can help some of you to become better developers. Thank you!
00:12:10.230
Hey, lots of people! Thank you for being here again! Thanks to the organizers for the fantastic conference. Going to many conferences takes a lot of work to put together, so make sure to thank them later if you see them.
00:12:30.000
I just want to talk about something we are using in my company, Cookpad, to help automate workflows. Everybody is making pull requests and issues, and it’s just a nightmare, so we came up with this CP8 Bot to help us manage our daily work. This was initiated by one of our engineers, Yen’s, whom I forgot to credit, so I should say thank you to him.
00:12:55.410
What can CP8 do? The first thing we implemented was to manage stale issues. When something has been hanging around in the list for weeks and no one wants to look at it for whatever reason, if I go in and close something, someone's going to come back to me asking what I'm doing. But if CP8 does it, it's like, 'Oh yeah, thanks CP8!' It’s a different feeling.
00:13:25.620
We also want to optimize our time, so we don’t have other developers reviewing things that aren’t quite finished. We tag every pull request with a WIP (Work In Progress) label. CP8 automatically tags that pull request for you, so you can set your filter and never see stuff that isn't ready for review.
00:14:01.320
Also, if you remove the WIP tag from the header, CP8 will go in and remove that tag for you. One of the really cool things is that we have a review loop, which is usually chaotic. So, when a new pull request is made, CP8 will post in a review channel in Slack. We limit this to smaller pull requests to optimize the review process.
00:14:30.470
If it’s less than 50 or 100 lines, it will notify people directly. We also use a recycling symbol to indicate when something is ready for review. This way, when something is approved, it saves time for the developers, and they know their pull request is done.
00:15:15.320
We encourage everyone in the company to contribute issues and ideas to a global inbox, which is a great practice. We’ll triage them and prioritize them, intending to move them to our squad repositories. But, we cannot move things between repos directly in GitHub.
00:15:49.780
However, CP8 comes to the rescue! By using labels, you can specify different repositories to which you want to move an issue or a pull request. Just label it, and CP8 will copy the original, move it to the new repo, close the old one, and tag it. This way, we can still maintain a master list of our issues and have a central inbox while moving things around to the right squads.
00:16:32.480
Also, CP8 has a command-line interface. This was actually the original feature of this tool: you can start a pull request by doing CP8 start [title], and it will create a branch. When you’re ready, you can do CP8 submit, which creates a pull request in GitHub and opens it automatically. It’s open source, and there’s plenty of information on GitHub at cookpad.
00:17:01.060
That's it! Thank you very much, Miles! For the next talk, many of you probably have used microservices and maybe even done them well, but now we are about to learn how to do microservices badly. Welcome, Maz!
00:17:26.130
Thank you! I really regret signing up for this by the way. Okay, how to do microservices badly? My name is Maz, and I am currently a tech lead at Not On The High Street, which is an e-commerce company in London. Just to give you a bit of background: we have 3.5 million active users, 150 million in yearly sales, 200 staff, and a 40-person tech team.
00:17:41.020
The reason I’m saying this is that it's essential to know you can have code of questionable quality in production and still be making good money. Here’s what the Rails app looked like three years ago. We had something like 240,000 lines of code at that point in time, and it’s really about 65,000 lines of application code. We asked, 'How do we add new features, scale, and move quicker?' So we decided to implement microservices. Hooray! Trust me, I’m a developer!
00:18:21.240
At our company, we have a culture of trust. Even though we have several development teams, we have always trusted them to code as they see fit. But with microservices, that proved to be complicated. Imagine we have four or five technical teams working on this monolith, and then we say, 'Okay, go off and build microservices whichever way you want.' One team might say, 'I come from Java; I’ll build this payment service in Java!' Then, the Ruby people would say, 'Well, I don’t like Java, I’ll build another Rails microservice,' and then of course, there’s a developer who thinks, 'I don’t like Rails either, I’ll do it in plain Ruby.'
00:19:27.330
Then there's another group that thinks, 'The model is fine, I’ll just deploy multiple instances in production that start the app in a different way.' Each of those takes about 8 gigabytes of RAM. Meanwhile, the Java team is happily building more things. And then someone else discovers Go and thinks, 'We should use that.' So it looks a bit chaotic now.
00:20:21.450
It eventually became evident that each team was building out their microservice in a potentially overcomplicated way. By trying to decentralize and trust the developers too much, we lost sight of cohesion. We put all our focus on solving technical problems but didn’t focus on getting the teams aligned, working together, and having the same tools. There was no strategy to do this correctly.
00:21:14.880
So we are fixing it. We are making changes and taking steps to get better aligned as a development team because I actually love my job. It’s an excellent place to work, and if you want to work in London, message me! Thank you!
00:21:41.840
Thank you very much, Maz! If you need consulting on microservices, Maz is available. The next and final talk is from Gabi on the power of community. I just need to find it— so you can take the microphone and fill in while I find your presentation.
00:22:02.990
Thank you.
00:22:04.980
Hello everyone! As you may already know, I am Gabriella, and I come from Bulgaria. I’ve been working with Ruby for the past three years, and I want to dedicate this lightning talk to all the Rubys out there.
00:22:15.660
It’s my first year at the university, and I started studying C++. Unfortunately, the teachers weren't really interested in teaching, which left me feeling disappointed and discouraged. At the end of the year, I blamed everything on the language, thinking it was too complex and that I wasn’t good enough to grasp it. The next year, I took Ruby courses, which turned out to be one of the best decisions in my life.
00:22:58.790
I came across people who were so passionate about teaching, encouraging beginners, and explaining concepts that I started believing in my own capabilities. This was the moment I realized I shouldn’t be blaming C++ or myself for my first-year failure. I recognized that with the right help and guidance, I could do better. Half a year later, I started my internship with Ruby, and another six months later, I began volunteering at the Oscars event in Bulgaria, feeling inspired to pay my knowledge and experience forward.
00:23:58.680
Since 2015, being involved with Real Girls has been one of the most rewarding satisfying experiences in my life. What I’m trying to say is that the Ruby community has played a significant role in shaping me as a developer. Ruby has brought me together with wonderful people. It taught me that it’s okay to ask questions, it’s okay to be a beginner, and not to know everything because there is always someone out there willing to help or at least give advice.
00:24:55.400
Three years after writing my first Ruby code, I gave my first talk at the Bakken Ruby Conference in Sofia. It gathered around 150 people, and I was incredibly nervous, not because this was my first big talk, but because I was presenting to people with far more experience and knowledge than me. Long story short, the talk went far better than I was expecting, and the positive feedback I received is the reason I am here today, giving a lightning talk in front of about 600 people.
00:25:47.480
So, I just really wanted to say thank you to all of you for being such a supportive community. This year’s diversity tickets are just another example that the Ruby community cares about its future. Words of appreciation matter! So I just wanted to remind you how wonderful you are and that you should continue doing good work. And to all the beginners, don’t hesitate to ask questions or search for help. Look for mentors, workshops, or organizations because people are really kind!
00:26:19.230
Thank you!