Embedding Rust in Ruby

Current 1602 student Matt Pindell shares a quick tutorial he created on the basics of embedding Rust code within Ruby by using FFI (foreign function interface) to speed up an implementation of nth prime: Acccess the screencast by clicking on the screenshot above or you can find it on Youtube here .
Read Full Article

What is the Law of Demeter and Why Should I Follow It?

A few times I've been told during code review that something violates the Law of Demeter. This method for example. class User def user_info "#{user.name}, #{user.department.name}" end end Which led me to ask: what is the Law of Demeter, why should I follow it, how do I know if I'm violating it, and how do I avoid violating it? The Law of Demeter is formally defined as, A method of an object may only call methods of: The object itself. An argument of the method. Any object created within the method. Any direct properties/fields of the object. The above code sample violates the law with "user.department.name" because it's calling name on the user's department, and department is an entirely different object from a user. In general it is better if one class does not have to know about methods from another class, in other words when the classes are "decoupled". This is because it makes the code more flexible. For example in our code sample, there is only one department for a user. But what happens if things changed so that a user could have many departments and we wanted the only use the first one for our user_info method? We would then have to say: class User def user_info "#{user.name}, #{user.departments.first.name}" end end This seems reasonable for now but what if we used "user.department" in multiple places? We'd have to make the same change wherever it was used, which would be cumbersome. So how do you avoid violating the law? You could make a custom method in the User class called "department_name": class User def user_info "#{user.name}, #{user.department_name}" end def department_name departments.first.name end end Now the department_name is an immediate property of the user itself, satisfying the law and also making it easier to make future changes if we...
Read Full Article

How I Learned to Stop Worrying and Love the Bomb

Errors are your friends. This idea was difficult for me to grasp when I first started programming. A typical block of work time would consist of the following: Write some tests and some code that should theoretically make those tests pass Run the tests Get terminal output similar to the image above Panic I would watch my screen fill up with terrifying error messages and I'd freeze. Yes, I know my code is broken thankyouverymuch. It took me a while to appreciate that what lay before me on the screen was not a pile of computer word vomit but rather a roadmap of sorts, and all I needed to do was learn how to read it. To be completely honest, I hated school until I figured this out. One of the most important things a new developer can do is learn to read a stack trace. So, how does one learn to read a stack trace? Read on for some tips: Practice. The more error messages you read, the easier it gets. This is true for just about everything when it comes to programming, but especially so with stack traces. If you're just starting out, ask someone for help. The more you practice, the better you'll get at learning to... Recognize Patterns. If one error is intimidating to a new programmer, then multiple are just downright scary. But often, a single mistake in one's code will have a cascading effect across the entire codebase. Stack traces let us see this easily. For example, if five tests are all failing with error messages that all implicate a particular method, chances are good that this is a place to start troubleshooting. In this case, the stack trace becomes a step-by-step guide to fixing errors or refactoring. Learn What to Ignore. Most stack...
Read Full Article
Upload Background Image
Drop File