westoque

You already use TypeScript

Sun, 19 Apr 2015 21:00:00 +0800

You probably heard of this new language on top of Javascript called TypeScript. TypeScript promises to make your code better and maintainable by adding more features on top of Javascript such as types and classes.

Javascript purists on the other hand, don’t want types and infer that it is one of Javascripts strengths. That is correct, although if you used a popular open source Javascript library in the past few years, you might’ve come across some documentation that looks like this.

Now, if you looked at the documentation, look at that! You see types! Isn’t that ironic. So you have been using types all along, you just didn’t notice it yet. This pattern is actually used by a lot of big Javascript libraries like Facebook’s JS SDK, Yahoo’s YUI, and many more.

I have been using TypeScript myself lately. And I’m all for it. It makes your code much more readable, and eliminates some boiler plate code checking, like checking for default values and types.

The best thing I like about it is that if you are working on a huge codebase, it would be easier to work with the code by knowing which code breaks because of the compiler, not that we’re all dependent on it, but I wouldn’t mind having some type of checking.

So there you have it, I think TypeScript has a lot of potential. Especially for people who write libraries. If you use Javascript, you might as well use TypeScript.

Discuss on hacker news.

A Huge Ruby Problem

Wed, 13 Nov 2013 11:00:00 +0800

Oh my beloved ruby! How I thought you were perfect… This was the case until I realized it had a huge problem resolving classes.

Given this class:

ruby class MyModule::File end

When I try to use MyModule::File it would always resolve to the standard File class, which is not what I want and gives me a warning:

sh > MyModule::File (irb):4: warning: toplevel constant File referenced by ContentItem::File => File

I was wondering what I was doing wrong, it took me awhile to figure out, but then this stack overflow answer beautifully explained it.

It seems that naming classes under modules that have the same name in the global space is a bad idea because of how ruby resolves classes. So as a workaround, just to be safe, I always try to name my classes diffrently from any of the gem/lib classes that I use. So for this use case, I can use MyModule::FileItem.

Add a "context" Block to Rails Tests

Tue, 12 Nov 2013 06:00:00 +0800

I’ve been ranting for awhile now on how hard it is to organize your tests in rails using its default test framework. Meaning it doesn’t provide a context or describe block like shoulda or rspec does.

Although recently I think I found the solution. Randomly looking around the devise library code, I found this little snippet that adds “context” blocks to the default test framework so its easier to organize your tests.

Here’s an example:

```ruby class SampleTest < ActiveSupport::TestCase # # This method lets us add “context” blocks in our tests # def self.context(name, &block) instance_eval(&block) end

# We can then use the context block… context “When saving” do test “should validate name” do # … end end end ```

So there you go. A quick way of adding context blocks to Rails.

Coding is not Computer Science

Sat, 21 Sep 2013 06:00:00 +0800

Programming in college definitely taught me a lot of things. Mostly about data structures and things we consider to be good and fast design. I found them to be extremely useful when working on very “complex” problems.

Although recently, I dedicated some time to teach some people how to program. Most of them did not take Computer Science or take any programming classes before so I thought it would be an interesting experience. What I discovered was that it was easier for people to understand the uses of the piece of code by explaining it to them simply without the scientific bullshit.

For example, in Ruby, I would have an Array that I’ll use as a Stack. And going back to our data structures class, we know that we can push and pop from this Stack. So instead of explaining how Stacks work, we can just ask ourselves on what we wanted to do with our Array. Do we want to put something in the start or end of it? Then, we figure out what the method is by googling or looking at documentation. I’ve found this to be the most effective method to get people to start building things and not worry about the technicalities. Sometimes, technicalities make things more complicated and also tends to scare people off.

Of course, this is not the path to becoming the next amazing developer but through time, they will get exposed to more things that will lead them to learn deeper topics, slowly.

Discuss on hacker news.