RubyConf 2015

Las siete batallas que debes librar al comenzar un proyecto Ruby

Heidi Waterhouse  · 


HTML (pincha para descargar)



Extracto de la transcripción automática del vídeo realizada por YouTube.

- So, this talk is about The Seven Righteous Fights that you should be having already. And it's about your inevitable failures, because I know about these things. I'm sorry to tell you you're going to fail on these things, but I'm here to tell you how to make it better.

It's been 20 years since I learned HTML in an English class we did some HTML coding on a project on Arthurian legends. . . So, that's where I'm coming from technology wise. In the intervening time, I've been the Lead Tech Writer on at least 10 new products, and I am a person who has been trained to see and analyze patterns and nuances in how projects work, and I'm going to tell you there're some common points of failure.

We get stuck in a rut. This is a picture of a central African highway. That's what it looks like when it's going well because you get stuck in a rut, you drive trucks over mud, you get a rut. We all have ruts in our programming, we all have places that we get comfortable in how we work.

Like, I am an early stage person, I really like the start of a software project, I really like being in there, but that means that if you're only an early stage person, or only a mid-stage person, you don't understand the pain points of other stages other stages of software development.

If you're one of those people whose like, "I only work for the first two years of a product, and then I leave," you don't know what happens at your sixth when everything goes to hell. So, who here has gotten the retirement lecture on compound interest? Yeah, right? Like, start saving now or your retirement is going to suck, compound interest is magic.

Compound interest is also horrible because it applies to technical debt. The more you make mistakes in the beginning, the more horrible it is to fix them later. So, this is a story about a product that I was working on with a startup. We were doing this really cool thing, and we were scrambling to make it ready for a trade show.

You all been in that position? You're like, "Gotta get it ready, gotta get it ready. " And so, we were stripping out everything that was unnecessary as fast as possible, and then we went to the trade show, and we got the proof of concept contract, and we were so excited, and then we realized it was for a company in Brazil, and one of the things we had stripped out was localization.

So, what we had to do was take all of the labels that we had hand coded in English, and point them back in to something that could be translated. It cost five days to fix it the wrong way, which is just to say out Portuguese hard coded labels in. It cost two weeks to fix it the right way, which is to say put references to a list that you could translate it.

I bet you have all at some point in your career hand coded a label. Don't do it! Because it's gonna cost you five days to fix it wrong, and two weeks to fix it right. And that's in the early stage of a product. As you get later and later into a product, it's gonna cost you months.

It's like, oh, localization is so expensive. It's not that expensive it you do it at the beginning. You say to yourself, "Well, I don't need to do that right now, I'm just gonna get a minimum viable product out. But I'm telling you that leaving these things out till the last minute, or until after you get your first demo or prototype out, is like leaving yourself to shove chocolate chips into an already baked cookie.

It's bad for the chocolate chips, and it's bad for the cookie. You don't want to be doing this, you want heavier cookies baked, or your chips baked in. So, that's localization. Here are the things that I know you can do for localization. You can make all of your labels refer to lists so it doesn't matter how you're doing this.

You can avoid ever putting words in your images. Don't put them in your logo, except for the company name, and don't rely on screen captures to be doing your work for you. Don't say, "Read this screen capture, so that you know how to do our product," because it's gonna look different in another language.

Build in support for extended characters. It is dehumanizing and extremely rude to tell people they cannot enter their name in the way that their name is. I'm not saying their real name, I'm saying their actual name. Their actual name is really important to someone even if it's something that you think is frivolous and full of emoji’s.

The late Noreen Plunkett used to keep a list of all the ways that people would mangle her name, because she had some Celtic diacriticals in there, and nobody could handle it. Like conference registrations, like webpages, there was just this huge list of ways that people had disrespected her core identity.

It doesn't take that long to build in full character support. Security, okay, brace yourselves 'cause you all know this could be a book, right? But, let's talk about some easy wins. The internet is not actually a series of tubes connected by guys on ski masks despite what we have been told in the television.

It is complex and beautiful, and probably nobody's gonna find you at first if you're a new product, but eventually there will come a day when you will have to write a super embarrassing email because your Waffle Buddies app has been compromised, and someone has but everyone's syrup preferences up in a paste bib the world to see.

Do you want to write that super embarrassing (laughs) thing? No, you do not. Security is neither cheap nor easy, but it beats the alternative which is fixing things in a hurry, and expensively because it's gone wrong. You should hire somebody who knows about security, so that you can make sure you've covered your bases.

You don't have to hire them forever, you don't have to have an onboard security person, although it's probably a good idea. But you have to be thinking about how you can do this better. If there was one thing that I could convince everyone to know in their heart, deep in their heart, if there was one thing I could convince everyone to know, it is that authentication is not authorization, authorization is not security.

Just because you can prove you know who somebody is, doesn't mean that you're letting them in the right places. Just because you're letting them in the right places, doesn't actually mean your data is secure. I wish that there was like a children'’s book on this, I'm serious.

Because we're just not teaching it, we're confounding these things all the time, and it's it's horrifying. Leave room for encryption. You can use SSL internally. Already, there's no reason you can't be using that in your internal things, and when you go to expand, that's gonna be easier.

You should be using HTPS for all of your pages, not just the front one. I know you've all seen websites like this here, like, "Oh, HTPS! What, why did you switch?" "Why is it suddenly insecure, I don't feel happy about that. " If you bake that in from the beginning, if that's just the default for how you code something, you're gonna have a much easier time when you have 300 pages and you have to do a security audit, which is what I'm doing this week at work.

[ ... ]

Nota: se han omitido las otras 3.459 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.