00:00:04.250
Hello, I'm Ben, and this is Lincoln, the red beard. We were asked to put together the lightning talk session, so here we are. We created a one-page site and received a number of submissions. I wanted to explain how we selected the talks. We have six talks, each lasting five minutes. We stored them in a database, removed the names, and selected them based solely on their topics. As a result, we didn't know who the speakers were, but we were aware of the topics they presented. We put our thinking caps on and chose the best possible submissions for this session.
00:01:02.480
Let me tell you, Objective-C is actually very interesting. Trust me, I haven't gone crazy! As Mary would say, it's super neat. Imagine taking C and adding a tablespoon of salt, a bit of Smalltalk, and a whole bunch of fun, and voilà—you have Objective-C. The biggest complaint, traditionally, has been its verbosity. Thankfully, this verbosity often translates into well-designed and easy-to-use APIs. Like Ruby, Objective-C allows monkey-patching, which is pretty cool. Despite being a compiled language, Objective-C has an equivalent to Ruby's alias method chain called 'swizzling.' If any of you have jailbroken your phone or used symbols on a Mac, you might be familiar with swizzling, where one method rewrites another to invoke it dynamically.
00:01:51.840
Objective-C has a wide range of APIs, and unlike some libraries in Ruby, the quality of APIs in Objective-C is continuously evolving. While about 50% of them might frustrate you, we all know and love blocks in Ruby. Objective-C just recently got blocks, and they work quite well. Another benefit is that Objective-C has Automatic Reference Counting (ARC), which functions similarly to garbage collection but at compile time. This makes development smoother.
00:02:34.950
Most importantly, it's worth mentioning that Objective-C is not C++. As a compiled language, it is enjoyable to work with, and while its syntax might initially seem daunting, it becomes quite pleasant once you get accustomed to it. I encourage you to give it a shot. Thank you for listening! I'm Darcy, and that concludes my talk.
00:03:42.530
This talk was inspired by a recent Rails vulnerability, which stirred a lot of emotions in our community. There was outrage, trolling, and the usual drama surrounding it—all the while, we're meant to be nice. However, we paradoxically get addicted to the drama. Ruby's ethos of 'convention over configuration' comes from DHH's influence. In short, we see binary camps: Ruby is either slow or fast, and Rails has been criticized for being slow to test but fast to write. We have camps arguing over dynamic vs. type-safe languages. Some have suggested that if we had used a type-safe language, a vulnerability like the one we faced wouldn't have occurred because those languages can't evaluate code.
00:06:02.800
Yet, the recent vulnerability was a community mistake, not a programming error. The incident was not due to poor code but rather a series of interconnected components that unexpectedly compromised many applications. The Rails community faced backlash for this. It’s easy to forget that web development itself is a compromise. If we wanted to write the most secure applications, we might have to resort to obscure, low-level languages. Rails allows us to develop applications quickly, though they might not perform optimally. That's why delivering value remains crucial. We should approach critiques more delicately; remember, we are all part of the same community. I can’t conclude this talk without sharing a beautiful picture since after all, aesthetics are important. Thank you!
00:07:56.370
Thanks, Johnny. One thing we forgot to mention at the start was that there are prizes for the best talks, thanks to our friends at Travis CI. We have two prizes: a V60 kit and a grinder. Keep that in mind as we continue!
00:08:20.330
Next, we have Toby Peter Hede, who will perform an 'Ode to Seventeen Databases' in five minutes. If you saw my talk yesterday, I've replaced Linux with a much more dramatic premise. I wandered lonely through the cloud, floating high over virtualized software on a hypervisor, or something—a poetic nod to databases.
00:08:39.090
This talk serves as a guide to help you scale your web applications as efficiently as possible. First, let's talk about Alchemy DB. If you like Redis but miss SQL, and you think Lua is good for data, this is a great option. Cassandra is excellent as a column database, as long as you can figure out how to structure your data correctly. It is named after the Greek goddess of eventual consistency. CouchDB is useful for storing documents, but getting them back out can be a struggle. Couchbase is like Memcached but with CouchDB’s capabilities. Elasticsearch isn’t a database in the traditional sense, but it serves as a fantastic API for retrieving JSON documents. Then there's Hadoop, which is incredibly popular right now.
00:11:01.400
Hyperspace is a favorite topic of some developers, and MemSQL claims to be the fastest—it compiles SQL into C++, ensuring high speed by running entirely in RAM. MongoDB functions similarly to CouchDB in that it can lose documents at web scale. MySQL is the go-to database if you aren't using PostgreSQL, but you might consider looking into a fork since, well... Oracle. Neo4j is fantastic for graph databases; if you're building a social network, you might end up choosing MySQL like Facebook did, but deep down, you might wish you had opted for a graph database.
00:12:43.210
React is a massively distributed key-value store, and while you might not need it, from an engineering perspective, it’s fascinating. Erlang’s platform, Erlang OTP, is great for distributed systems, and PostgreSQL is a beautiful database that's hard to describe. One thing I love about PostgreSQL is its hstore feature; it's SQL, NoSQL, and allows you to embed V8 directly into it!
00:13:04.130
Redis is for times when you don’t want to admit that you have a queue. RethinkDB is what one would expect if they valued ACID transactions but it can be a bit slow. Finally, there's Spanner, Google’s incredible geographically distributed, tightly consistent, transactional SQL database that requires atomic clocks and GPS. Essentially, Google is like, 'Go figure it out'—thank you.
00:14:40.240
Thank you, Toby! Our next speaker is Robert Postill, and his talk is titled 'When I Load Up This Web Page, Rails Girls is More Awesome Than Falling Face-First Into Your Food.' I should have probably noted the name of the talk properly.
00:15:29.800
Who am I? Well, it doesn't matter because I consider myself one of the least qualified people to be discussing this topic. Why should you participate in Rails Girls? I’ll give you three reasons. First, consider my daughter, who, in about 18 years, may become a geek. I can’t teach her all the technical skills, but I can offer some guidance in computing. Second, I urge you to look at the state of our profession through this website, which I believe is a perfect example of the soul-crushing side of our industry. Lastly, socializing is another reason. As English people, we sometimes struggle to socialize, but a year ago, at a party, I found myself engaging in fascinating conversation until someone bluntly asked, 'What do you do?' I sheepishly answered, 'I’m a computer programmer,' to which a guest asked if I still lived with my parents.
00:17:32.990
So, what exactly is Rails Girls and why is it fun? It’s an introductory two-day workshop where participants get a laptop, we install Rails, and create an application. By the end of the workshop, participants have a basic app deployed on Heroku, which is a huge accomplishment!
00:17:47.680
It is fun because it involves creating something, and that’s what we do as developers—we create. Contributing to the community is magical, and engaging with new learners can be illuminating. For instance, during the workshop, a participant asked me about the difference between brackets in code, and I was reminded of how intuitive some of these concepts may seem to us but can be confusing for others. We need to discuss the intricacies of programming because they may seem similar on the surface yet be distinctly different in various contexts.
00:18:51.740
I want to sell you on participating in Rails Girls. Running a Rails Girls event requires three key things: a venue, couches, and food. The community is fantastic, and the support is overwhelming. Sponsorship is usually easy to acquire, leading to a successful event.
00:19:20.320
So I encourage you to go to the Rails Girls website, sign up, and organize a Rails Girls event in your city. Thank you all!
00:22:43.440
Next up, we have Cameron Barrie, with a talk titled 'Design Your API.' I only have five minutes to discuss designing APIs. If you’re creating an API, it's crucial to think about design. I used to work extensively in Ruby, building numerous APIs for touchscreen kiosks. Now I primarily write iOS applications.
00:23:11.580
Bad APIs complicate the process of crafting fast, stable apps. If the APIs I provided have issues, it reflects poorly on the apps I now consume. You want to establish good APIs to facilitate the app development process. A good API reduces the need to bake complex logic into the application that needs updates. Your clients are using different devices, and you can't always guarantee they'll update made in the App Store.
00:25:19.420
So here are some tips: always version your APIs. If your API changes unexpectedly, it can break applications in production without a quick fix. Providing structured JSON responses ensures clarity—don't leave the API as a second-class citizen in your view hierarchy. The API design is critical, and it’s about the experience individuals have when interacting with it. Consider separating user data URLs from JSON responses; this natural design will improve usability.
00:27:12.130
When responding to client requests, don't just convert your model to JSON without considering the context—ensure the response is crafted with care, just like creating a document in HTML or CSS. The takeaway here is to treat your APIs with love and attention, making them as good as the front-end and testing paradigms that we already uphold in our projects.
00:28:44.820
Thank you all for being so supportive today!
00:29:08.310
One quick note is that we contacted all the speakers at lunchtime today, so they had about five minutes to prepare for their upcoming talks. This is an admirable feat! Now, let's welcome Jason and Odin, who are excited to present!
00:30:34.400
Alright, we're going to talk about fresh! Currently, we face issues with managing dot files. How many of you have your dot files versioned? Thanks to a few helpful resources on GitHub, we created a solution to facilitate the organization of dot files. Structuring your configuration files into small segments allows for easy versioning.
00:31:26.160
For those who work together, sharing configurations becomes seamless using this new tool. Fresh merges your shell files, handles config files, and even assists with script management. Experiment with the system; if you prefer to maintain your existing setup while benefiting from fresh for sourcing from others, it delivers a well-crafted and intuitive experience without friction. Check out freshtool.com for more details!
00:32:21.390
As we conclude the lightning talks, please imagine a few minutes of elevator music while we deliberate on the judging process!
00:32:49.200
Okay, we've made a decision now. I'm going to call Josh and Konstantin from Travis CI to present the prizes. After careful consideration, we loved the talk about the sixteen databases. They brought a unique perspective, and we’d like to award a V60 kit and a little grinder for this excellent presentation.
00:33:30.520
Upon deliberation, we also felt that Robert Postill's storytelling about his daughter and the future of coding in our community was noteworthy. Congratulations to him, receiving an Aeropress and various coffee equipment as a prize!
00:34:01.090
We appreciate all our presenters today; they shared fantastic ideas, and it was a fun session. Thank you!
