Omg I been super busy. Doing what? I have no idea. I think I took a short vacation, and then work went all hell bent busy, and the random side things I work on went all ape nuts crazy too.
Sadly, I didn't take my deep dive into Erlang or Elixer yet and it's fallen on my list of things to get done. More recently I'm actually getting my windows redone (yay). I also recently attended NationJS, a great JavaScript convention. Got to listen to a great talk on Brackets, an open source editor for the web. It's actually pretty slick. You type and it reloads immediately. Nice JS debugging. And looks pretty nice. They actually develop it using Brackets. I love when products eat their own dog food. Check it out if you have time. They also make it real easy to contribute. They have what they call starter issues, which are like bugs for people new to brackets.
Also one last bit of coolness. If you have time or have figured out how to halt time, check this list out:
https://github.com/vhf/free-programming-books/blob/master/free-programming-books.md
Monday, October 14, 2013
Tuesday, July 2, 2013
Dave Thomas Recap and Elixir Intro
Just wanted to follow up with my talk with Dave Thomas and various other fun speakers. Dave didn't speak for very long, but the little he did was very impressive. Let's just get right into it. Dave talked about Elixir, which as you already know from my last post is a Ruby like syntactical language that runs on the Erlang VM. Now the ErlangVM is dang cool, and for more information, read my last post :)
So pretty syntax? That's it?? Well, there is quite a bit of power in more than just the syntax, but I'm not ready to go into all that yet in this post. I'm here just to talk about the pretty syntax. How pretty you might ask? Let's say you wanted to solve the infamous Fibonacci series. Everyone's done this. The concise way is typically to use two methods, one that you call recursively to build your result. And then you're a clever person so you do some sort of memoization or dynamic programming approach. Yay (I'll probably post more about these approaches later, but for now, just wiki them)! Well throw all that stuff out and check out the Elixir approach:
defmodule Cool do
def fib(0) { 0 }
def fib(1) { 1 }
def fib(n) { fib(n-1) + fib(n-2) }
end
IO.puts Cool.fib(10)
Ok what??? Yes, that's the program. It looks like all I did was describe the problem, there's no way that's actual runnable code. But it is. Taking from the Erlang gentle intro from last post, every bit of code is name spaced, or in some sort of class type object, or in Erlang, a module. We simply describe the problem:
If we pass in 0, we want 0.
If we pass in 1, we want 1.
If we pass in anything else, we want that thing called using this statement but subtracting one and then added to the same but substracting two.
Ok not as concise as the mathmatical symbols, but you get the idea. We describe the problem and bam! It just works. This works because of an Erlang construct known as pattern matching. It's really not that complex. So if we call
Cool.fib(1)
This method matches the second of the equations up there, b/c the argument is 1. If we call
Cool.fib(0)
it matches the first equation (function) because the argument here is 0. And if we pass something that's not 1 or 0, that falls into n which then calls the third function. Which as you can see, will cause a recursive call. Pattern matching is awesome and allows us to define the problem in terms of equations instead of if/else's. Dave boasts that using this, you can write a whole program devoid of any if/else branching. He also quickly created a program that spawned multiple processes and had them all work in parallel to compute some result. I'm not going to get into that now, but just now that it's out there. I think the best take away I had from his talk was his last quote:
"If you aren't writing functional code in the next few years, you'll be writing maintenance code."
So pretty syntax? That's it?? Well, there is quite a bit of power in more than just the syntax, but I'm not ready to go into all that yet in this post. I'm here just to talk about the pretty syntax. How pretty you might ask? Let's say you wanted to solve the infamous Fibonacci series. Everyone's done this. The concise way is typically to use two methods, one that you call recursively to build your result. And then you're a clever person so you do some sort of memoization or dynamic programming approach. Yay (I'll probably post more about these approaches later, but for now, just wiki them)! Well throw all that stuff out and check out the Elixir approach:
defmodule Cool do
def fib(0) { 0 }
def fib(1) { 1 }
def fib(n) { fib(n-1) + fib(n-2) }
end
IO.puts Cool.fib(10)
Ok what??? Yes, that's the program. It looks like all I did was describe the problem, there's no way that's actual runnable code. But it is. Taking from the Erlang gentle intro from last post, every bit of code is name spaced, or in some sort of class type object, or in Erlang, a module. We simply describe the problem:
If we pass in 0, we want 0.
If we pass in 1, we want 1.
If we pass in anything else, we want that thing called using this statement but subtracting one and then added to the same but substracting two.
Ok not as concise as the mathmatical symbols, but you get the idea. We describe the problem and bam! It just works. This works because of an Erlang construct known as pattern matching. It's really not that complex. So if we call
Cool.fib(1)
This method matches the second of the equations up there, b/c the argument is 1. If we call
Cool.fib(0)
it matches the first equation (function) because the argument here is 0. And if we pass something that's not 1 or 0, that falls into n which then calls the third function. Which as you can see, will cause a recursive call. Pattern matching is awesome and allows us to define the problem in terms of equations instead of if/else's. Dave boasts that using this, you can write a whole program devoid of any if/else branching. He also quickly created a program that spawned multiple processes and had them all work in parallel to compute some result. I'm not going to get into that now, but just now that it's out there. I think the best take away I had from his talk was his last quote:
"If you aren't writing functional code in the next few years, you'll be writing maintenance code."
Monday, June 24, 2013
This Elixir Comes From What?
Wednesday I'm going to a talk with Dave Thomas (http://en.wikipedia.org/wiki/Dave_Thomas_(programmer)). It was his "Agile Web Development with Rails" and "Programming Ruby" that started me with my love affair with Ruby and Ruby on Rails. He's coming to talk about his latest book, "Programming Elixir". I knew about Elixir from various blogs, but I was never particularly interested in it. To me, it was just Erlang with Ruby syntax. But knowing that Dave would be taking about it in a few days, I decided to take another look at it. On closer inspection Elixir turns out to be very interesting.
First off, what is it?
"Elixir is a functional meta-programming aware language built on top of the Erlang VM. It is a dynamic language with flexible syntax with macros support that leverages Erlang's abilities to build concurrent, distributed, fault-tolerant applications with hot code upgrades."
-- Jose Valim (creator)
In some cases, Elixir will actually run faster than Erlang. That's pretty damn cool. And if you're reluctant to try it out, check out this blog post by one of Erlang's creator, Joe Armstrong (http://joearms.github.io/2013/05/31/a-week-with-elixir.html). If he likes it, there must be something to it.
So while reading the docs, I thought, yep, this is very Rubyish. But I didn't understand the abstraction that it was doing from Erlang, and that bothered me. I hadn't done Erlang since college and figured it was time to get back in it, but really learn it this time. So this post and most likely some future posts are going to be my dip back into Erlang.
Erlang Background
Every language is created with a specific problem in mind to solve. Erlang started out in the 80s at Ericsson where they were trying to figure out the best way to build systems for their phone systems, switches and such. They examined over 20 languages and found that none of them totally suited their needs. So they took what they liked from each language, and with Prolog as it's syntactic inspiration built a new language with the following goals in mind:
1. Fault tolerance
The entire system should be stable enough to withstand errors that could occur.
- Erlang has light-weight processes that are all isolated from one another. They run in complete isolation which means that if one dies, it does not compromise the entire system.
- When processes die, they can tell other linked processes that they are dead. Using something like the OTP (Open Telecom Platform) framework gives you advanced process supervision in the form of trees that delegate responsibility for things like process restarts and restart timeouts.
2. Non-stop
They system should never go down nor should you ever have to take the down. Put simply, they should not stop.
- The system is fault tolerant so errors will not take the entire system down.
- Code can be hot swapped in. This means that you can actually push out newly compiled code while the system is still running. You also can choose which part of the system you want to deploy the new code to, so you get total control.
3. Concurrent
All the processes in an Erlang application are truely concurrent.
- There is a scheduler per core (with SMP -- Symmetric Multi Processing enabled) that will schedule the work to be done
- They employ preemptive scheduling so the developer doesn't have to worry about cooperative scheduling.
- All processes are equal. This means that no one gets special priority, internal Erlang processes get the same priority as your processes.
4. Distributed
Multiple Erlang processes can actually live on different machines and all communicate with each other. Erlang uses the actor model which means each Erlang process is itself an actor with a mailbox that can receive messages and choose what they do with it. Each process can additional send messages to any process. This is a very powerful mechanism and is actually built into the language without having to add any additional modules.
5. Soft real-time
Real-time is critical for applications like airplanes where processing in real-time could cost lives. Erlang was built for phone systems, so real-time is NOT a must. They are not bound to the same constraints as airplanes. This is the platform that Erlang was targetted for, and these laxer requirements allows such things as a garbage collector for the Erlang VM.
6. Prototypeability
This is a made up word coined by Lennart Ohman used to describe Erlang, but this really just means speed to produce code, or "time to market". Basically programmer efficiency and speed from inception to production.
- To allow programmers to work faster, Erlang was designed to be a functional over imperative language, which they believed would allow faster development.
- Run-time linking. Linking is done at run time allowing code to be hotswapped in. This is pretty cool, see the non-stop section.
Erlang has a compiler and that compiled code is then linked at run time and executed. As I mentioned above, Erlang has a virtual machine, called BEAM, or sometimes EVM. One of the awesome things about Erlang is that processes are cheap to create and all execute concurrently (to give a little more depth to this, you can actually configure three parameters to help you adjust your concurrency profile. -P for your process threads, these are actually green threads. -S which are the scheduler threads, typically one per cpu. These will schedule the green threads for execution. -A for your async threads that react to select and poll events).
Erlang isn't all sunshine and rainbows though. People have complained about the poor performance (notice that performance wasn't one of the goals of the language), the GC isn't that great, and of course the most common criticism is the syntax. Either way, I'm going to blog about my dive into the language, but for now I'll leave you with the canonical hello world:
Example
Save the following in a file named hello.erl (it must match module name)
-------------------
-module(hello).
-export([hello_world/0]).
hello_world() -> io:fwrite("Hello World\n").
-------------------
Then start Erlang by typing erl at the command prompt. Then type the following:
c("hello.erl").
hello:hello_world().
Notice the output.
A few things about the syntax:
1. All lines end in a period.
2. Module named 'hello', sort of like a namespace.
3. Export is a method that exposes internal methods to the outside world, sort of like building an api, or declaring public methods.
4. In the export, notice the brackets, they signify [method name/num of args]
5. -> is a function definition
6. c() is a built in Erlang method to compile
7. module:method() is how you invoke a method. Notice we called our module 'hello' and method 'hello_world'
And that's pretty much it. Until next time.
First off, what is it?
"Elixir is a functional meta-programming aware language built on top of the Erlang VM. It is a dynamic language with flexible syntax with macros support that leverages Erlang's abilities to build concurrent, distributed, fault-tolerant applications with hot code upgrades."
-- Jose Valim (creator)
In some cases, Elixir will actually run faster than Erlang. That's pretty damn cool. And if you're reluctant to try it out, check out this blog post by one of Erlang's creator, Joe Armstrong (http://joearms.github.io/2013/05/31/a-week-with-elixir.html). If he likes it, there must be something to it.
So while reading the docs, I thought, yep, this is very Rubyish. But I didn't understand the abstraction that it was doing from Erlang, and that bothered me. I hadn't done Erlang since college and figured it was time to get back in it, but really learn it this time. So this post and most likely some future posts are going to be my dip back into Erlang.
Erlang Background
Every language is created with a specific problem in mind to solve. Erlang started out in the 80s at Ericsson where they were trying to figure out the best way to build systems for their phone systems, switches and such. They examined over 20 languages and found that none of them totally suited their needs. So they took what they liked from each language, and with Prolog as it's syntactic inspiration built a new language with the following goals in mind:
1. Fault tolerance
The entire system should be stable enough to withstand errors that could occur.
- Erlang has light-weight processes that are all isolated from one another. They run in complete isolation which means that if one dies, it does not compromise the entire system.
- When processes die, they can tell other linked processes that they are dead. Using something like the OTP (Open Telecom Platform) framework gives you advanced process supervision in the form of trees that delegate responsibility for things like process restarts and restart timeouts.
2. Non-stop
They system should never go down nor should you ever have to take the down. Put simply, they should not stop.
- The system is fault tolerant so errors will not take the entire system down.
- Code can be hot swapped in. This means that you can actually push out newly compiled code while the system is still running. You also can choose which part of the system you want to deploy the new code to, so you get total control.
3. Concurrent
All the processes in an Erlang application are truely concurrent.
- There is a scheduler per core (with SMP -- Symmetric Multi Processing enabled) that will schedule the work to be done
- They employ preemptive scheduling so the developer doesn't have to worry about cooperative scheduling.
- All processes are equal. This means that no one gets special priority, internal Erlang processes get the same priority as your processes.
4. Distributed
Multiple Erlang processes can actually live on different machines and all communicate with each other. Erlang uses the actor model which means each Erlang process is itself an actor with a mailbox that can receive messages and choose what they do with it. Each process can additional send messages to any process. This is a very powerful mechanism and is actually built into the language without having to add any additional modules.
5. Soft real-time
Real-time is critical for applications like airplanes where processing in real-time could cost lives. Erlang was built for phone systems, so real-time is NOT a must. They are not bound to the same constraints as airplanes. This is the platform that Erlang was targetted for, and these laxer requirements allows such things as a garbage collector for the Erlang VM.
6. Prototypeability
This is a made up word coined by Lennart Ohman used to describe Erlang, but this really just means speed to produce code, or "time to market". Basically programmer efficiency and speed from inception to production.
- To allow programmers to work faster, Erlang was designed to be a functional over imperative language, which they believed would allow faster development.
- Run-time linking. Linking is done at run time allowing code to be hotswapped in. This is pretty cool, see the non-stop section.
Erlang has a compiler and that compiled code is then linked at run time and executed. As I mentioned above, Erlang has a virtual machine, called BEAM, or sometimes EVM. One of the awesome things about Erlang is that processes are cheap to create and all execute concurrently (to give a little more depth to this, you can actually configure three parameters to help you adjust your concurrency profile. -P for your process threads, these are actually green threads. -S which are the scheduler threads, typically one per cpu. These will schedule the green threads for execution. -A for your async threads that react to select and poll events).
Erlang isn't all sunshine and rainbows though. People have complained about the poor performance (notice that performance wasn't one of the goals of the language), the GC isn't that great, and of course the most common criticism is the syntax. Either way, I'm going to blog about my dive into the language, but for now I'll leave you with the canonical hello world:
Example
Save the following in a file named hello.erl (it must match module name)
-------------------
-module(hello).
-export([hello_world/0]).
hello_world() -> io:fwrite("Hello World\n").
-------------------
Then start Erlang by typing erl at the command prompt. Then type the following:
c("hello.erl").
hello:hello_world().
Notice the output.
A few things about the syntax:
1. All lines end in a period.
2. Module named 'hello', sort of like a namespace.
3. Export is a method that exposes internal methods to the outside world, sort of like building an api, or declaring public methods.
4. In the export, notice the brackets, they signify [method name/num of args]
5. -> is a function definition
6. c() is a built in Erlang method to compile
7. module:method() is how you invoke a method. Notice we called our module 'hello' and method 'hello_world'
And that's pretty much it. Until next time.
Wednesday, June 19, 2013
Back into the Rhythm
Back stateside. For those of you who don't know, I took a trip to Thailand and Cambodia for a few weeks and let me tell you, it was beautiful; I had a ball. The food was great and the sites were awesome. So now I'm back readjusting to the daily ins and out of work, fighting the last remnants of jet lag, and getting back into the groove of blogging and meetup-ing. I'll be sure to post pics soon, I've literally thousands to choose from :)
I've had a busy few days since being back though, I attended RubyNation pretty much the week I got back and had my water heater and AC die days apart from each other. So shopping for major home systems has kept me pretty busy, but I'm almost done with all that. So anyways, today's post is a fun article/interview of my friend Michele, who helped put on Las Vegas Startup Weekend a few weeks ago. It's interesting to catch a glimpse of the tech community out there and its great to know that it's thriving. Tech isn't the first thing you think of when you think Las Vegas, but people like Michele might change that.
http://skillcrush.com/2013/05/24/you-have-to-stay-hungry-to-stay-current/
She's currently hard at work on the next one, so check it out!
http://lasvegas.startupweekend.org/
I've had a busy few days since being back though, I attended RubyNation pretty much the week I got back and had my water heater and AC die days apart from each other. So shopping for major home systems has kept me pretty busy, but I'm almost done with all that. So anyways, today's post is a fun article/interview of my friend Michele, who helped put on Las Vegas Startup Weekend a few weeks ago. It's interesting to catch a glimpse of the tech community out there and its great to know that it's thriving. Tech isn't the first thing you think of when you think Las Vegas, but people like Michele might change that.
http://skillcrush.com/2013/05/24/you-have-to-stay-hungry-to-stay-current/
She's currently hard at work on the next one, so check it out!
http://lasvegas.startupweekend.org/
Tuesday, May 14, 2013
I Don't Want Your Exceptions
On the heals of my last post, in addition to not wanting your app, I also don't want your exception. I mean unless I'm developing it and we are in QA and something bad happens, then by all means, I want your exception. I guess in this case it's my exception, and my bad.
But when I'm not wearing my developer hat and instead wearing my regular user hat, I don't want your exception. Ideally I'd like whatever I'm doing not to fail, but if it does fail; tell me nicely that you were caught with your pants down and give me an alternative way to finish whatever I'm doing. I won't be mad, it's OK, we all make mistakes. But let me tell you what is unacceptable:
I'm sorry you use WebSphere and I'm sorry you never tested the "Forgot password" option. I guess your typical users have great memories. So what am I supposed to do now? I guess give up? I suppose go to your competitor? For now I'll settle for complaining about it on the internet. Thanks Aetna.
But when I'm not wearing my developer hat and instead wearing my regular user hat, I don't want your exception. Ideally I'd like whatever I'm doing not to fail, but if it does fail; tell me nicely that you were caught with your pants down and give me an alternative way to finish whatever I'm doing. I won't be mad, it's OK, we all make mistakes. But let me tell you what is unacceptable:
I'm sorry you use WebSphere and I'm sorry you never tested the "Forgot password" option. I guess your typical users have great memories. So what am I supposed to do now? I guess give up? I suppose go to your competitor? For now I'll settle for complaining about it on the internet. Thanks Aetna.
Monday, May 13, 2013
I've never wanted the app
I found something funny while backflipping through the internet (a funner imagery than surfing) and ran into this little gem:
http://idontwantyourfuckingapp.tumblr.com/
Hilariously foul language aside, the site is a collection of those annoying "Get the app!" advertisements that sites normally force you to click through before getting to the content.
I remember when I used to first run into these things, the flash of anger I'd get when realizing I'd have to click out of some annoying popup or page. But it became so ubiquitous that eventually I not only came to accept it, but expect it. It wasn't until they were all highlighted on this site did I realize how commonplace it was. Why would I want your app? Why would I want to download a single purpose tool that is only minimally better than your already mobile site?
So what really makes this so annoying? The fact that you built a mobile app doesn't make me annoyed. Build whatever you want, it's the fact you are throwing it in my face. "Hey look at what I made. Aren't I cool? Don't you want it?" "Well no, I don't want it, and I'd wish you'd stop asking already." It would be nice if there was a place on the screen (of offscreen on some menu) where I could click a button and download the app if I were so inclined. But making me tell you over and over I'm not interested makes me feel bad for you, and bad for myself for having to keep breaking your heart. "I'm sorry website, its not you its me. But if you ask me again I'm going to have to hurt you."
http://idontwantyourfuckingapp.tumblr.com/
Hilariously foul language aside, the site is a collection of those annoying "Get the app!" advertisements that sites normally force you to click through before getting to the content.
I remember when I used to first run into these things, the flash of anger I'd get when realizing I'd have to click out of some annoying popup or page. But it became so ubiquitous that eventually I not only came to accept it, but expect it. It wasn't until they were all highlighted on this site did I realize how commonplace it was. Why would I want your app? Why would I want to download a single purpose tool that is only minimally better than your already mobile site?
So what really makes this so annoying? The fact that you built a mobile app doesn't make me annoyed. Build whatever you want, it's the fact you are throwing it in my face. "Hey look at what I made. Aren't I cool? Don't you want it?" "Well no, I don't want it, and I'd wish you'd stop asking already." It would be nice if there was a place on the screen (of offscreen on some menu) where I could click a button and download the app if I were so inclined. But making me tell you over and over I'm not interested makes me feel bad for you, and bad for myself for having to keep breaking your heart. "I'm sorry website, its not you its me. But if you ask me again I'm going to have to hurt you."
Monday, May 6, 2013
Program Idiomatically
I like learning new languages. Each language is a reflection of the people that created and use them. For example, in most Asian cultures, the word for rice is often the same word for food. Every language across the world has these sorts of things about them and it really is quite fun to find a word that you can express succinctly in one language but is clumsy in another.
The same can be said for programming languages. If the language you are learning or have learned doesn't teach you anything new about their approach to solving problems or about the language design philosophy, then I'd say learning that language probably could have been skipped; or probably more realistically, you didn't take the time to really learn it.
If you are learning a language, really learn it. Don't just take what you know from a different language and do the same thing with the new syntax. Really learn the constructs of the language and their approach to solving problems. Read code, lots of code written by people who speak that language fluently and try it out yourself. Do it enough so that you can speak and write in that language similar to how the natives do. Solve problems, the bigger the better, and speak this new language with other people. See if they can understand you and your code.
They call this programming idiomatically and that brings us to this weeks article.
http://mrjoelkemp.com/2013/05/what-is-idiomatic-programming/
The same can be said for programming languages. If the language you are learning or have learned doesn't teach you anything new about their approach to solving problems or about the language design philosophy, then I'd say learning that language probably could have been skipped; or probably more realistically, you didn't take the time to really learn it.
If you are learning a language, really learn it. Don't just take what you know from a different language and do the same thing with the new syntax. Really learn the constructs of the language and their approach to solving problems. Read code, lots of code written by people who speak that language fluently and try it out yourself. Do it enough so that you can speak and write in that language similar to how the natives do. Solve problems, the bigger the better, and speak this new language with other people. See if they can understand you and your code.
They call this programming idiomatically and that brings us to this weeks article.
http://mrjoelkemp.com/2013/05/what-is-idiomatic-programming/
Monday, April 29, 2013
Passwords in Source Control
This weeks blog is from John Resig, creator of jQuery. He writes about a tip from his friend on the problem of how to store encrypted files in source control. Normally, he, and most people I'd say, would simply not store it at all. Instead it would remain blank and if you needed it, would email the person and get it that way.
Here he proposes a new solution, store an encrypted file and provide a way to decrypt and encrypt it. He uses OpenSSL, specifically CAST5 in order to perform this. He wraps this all within a nice makefile and boom, he has an easy way to perform the (de)encryption. For the exact specifics, check out the link. The makefile itself is very short and the main work is done all within the single openssl call.
Here he proposes a new solution, store an encrypted file and provide a way to decrypt and encrypt it. He uses OpenSSL, specifically CAST5 in order to perform this. He wraps this all within a nice makefile and boom, he has an easy way to perform the (de)encryption. For the exact specifics, check out the link. The makefile itself is very short and the main work is done all within the single openssl call.
Monday, April 22, 2013
Gittip
I recently read an article about Gittip.
Link
I've never heard of it before, but essentially it's a way of giving a tip to all your favorite open source contributors. I love this idea. As a contributor, the whole spirit of open source is to write knowing that you won't get monetarily compensated, but you're giving to the community to make it better. I love this altruistic mentality. But would't it be nice to have a way to say thank you?
It's awesome to be able to get something in exchange for your hard work. Having actual money is nice, but also having something as a way of knowing that your work is really appreciated and that the community wants you to continue. And with the money, being able to continue, assuming that it's providing you some kind of supplemental income to be able to give up long stretches of time to contribute.
At the end of the day, it's about saying thanks. There are other ways to say thank you, like finding the person and baking their favorite cake (might be creepy if you don't actually know them) or sending them that t-shirt they've been talking about (again I wouldn't recommend if you don't know them personally). But giving a small tip is another simple gesture that goes a long way (and a better alternative if you don't know them).
Link
I've never heard of it before, but essentially it's a way of giving a tip to all your favorite open source contributors. I love this idea. As a contributor, the whole spirit of open source is to write knowing that you won't get monetarily compensated, but you're giving to the community to make it better. I love this altruistic mentality. But would't it be nice to have a way to say thank you?
It's awesome to be able to get something in exchange for your hard work. Having actual money is nice, but also having something as a way of knowing that your work is really appreciated and that the community wants you to continue. And with the money, being able to continue, assuming that it's providing you some kind of supplemental income to be able to give up long stretches of time to contribute.
At the end of the day, it's about saying thanks. There are other ways to say thank you, like finding the person and baking their favorite cake (might be creepy if you don't actually know them) or sending them that t-shirt they've been talking about (again I wouldn't recommend if you don't know them personally). But giving a small tip is another simple gesture that goes a long way (and a better alternative if you don't know them).
Monday, April 15, 2013
Sassy Structure
Let's face it, everyone structures their css slightly differently. Or worse yet, they don't structure it all and it's just a mess of files all over the place
causing a sort of treasure hunt to try and find the freakin styling that's causing your div to float right (of course what I really mean is to use an inspector like the one in Chrome and see what style is causing the behavior). That's why I really liked this article:
http://thesassway.com/beginner/how-to-structure-a-sass-project
I liked how he layed out his sass files in a neat organized way. So a little backgroud, if you don't know what sass is, it stands for Syntactically Awesome St
yleSheets. It, along with some other competitors (namely LESS) provide a language that is a supserset of regular CSS. So you get all the stuff you're used to
in CSS, along with powerful constructs like variables, nesting, mixins, and inheritance, just to name a few things.
What I really like about John Long's project setup recommendation is the clarity and organization of how he lays out his files. If you need to change somethin
g, you pretty much know exactly which file to look in; no more hunting. And while developing, if you need to add a new style, you have a pretty good idea wher
you should add it.
Same goes for his really large project structure as well. He basically just copied what he did for the single project and divided it up into smaller 'sub-proj
ects' that all duplicate his basic directory structure. The only thing I'd add here is perhaps a 'common' directory that has shared styles that can be used ac
ross all sites.
So take a gander and see if it looks like you're project. The key here is organization and clarity. My personal belief and motto is that "coding is communica
tion". On one hand, you are communicating to the computer what you want done, and on the other you are communicating to other developers and future maintainer
s what your intent was. Your goal as a developer is to maximize this clarity so that there is no ambiguity and your intent can be immediately understood.
~
Friday, April 12, 2013
IP Address to Location
There are a bunch of sites out there that all translate ip address to location, but I needed a simple and easy to use API so I could do it programmatically. I found this little guy:
http://freegeoip.net/json/50.202.78.174
Instead of json you can also use xml or csv and the last bit is the ip address what you want to translate to location. I love it, stupid simple.
http://freegeoip.net/json/50.202.78.174
Instead of json you can also use xml or csv and the last bit is the ip address what you want to translate to location. I love it, stupid simple.
Sunday, April 7, 2013
Callback versus Promises
I like Node. I like the callback mechanism. I find the approach to multithreading very interesting. That being said, I should preface that I also like Java's Futures/FutureTasks. I guess what I'm trying to say is that I like things where I don't have to think about forking and joining (I'm ok with Java7's ForkJoinExecutor because again, I don't have to do it myself). Just do it for me and give me the result when you get it. In the meantime I'm going to make myself a sandwich, or whatever else I'm going to do while you're out fetching me whatever it is I asked for.
As such, this post got my attention:
http://blog.jcoglan.com/2013/03/30/callbacks-are-imperative-promises-are-functional-nodes-biggest-missed-opportunity/
James Coglan's basic assertion is that Node's decision to go with the callback mechanism was a mistake. Before I go much deeper, I'm going to summarize a bit just in case you tl;dr it. Essentially callbacks is at it's core an imperative construct while Promises (essentially FutureTasks) are more functional. Why do we like functional versus imperative again? Well because imperative tells the computer HOW to do something while functional tells the computer WHAT to do. Imperative programming mutates state of objects as those objects are passed from function to function. This means our programming is very dependent on the order of method invocations as well as the exact state of the objects over a given time. Functional programming deals with values. Arguments are values, and results returned from functions are values. Nothing is holding state. This essentially lets you parallelize a lot more because you never have fear or two threads potentially mutating the same object concurrently. For any given input, you will ALWAYS get the same result. 1+1 is always 2. But varX + varY could be 2 if varX and varY are both holding 1 at the time of execution. But let's say this method then mutates varX. Uh-oh, now depending on when you call this imperative method, you could get 2 or 3. Get it? Kind of? Good enough.
So why did Node go callback? Well because it's easier to understand. Promises are much more abstract.
Callback
makeSomeBlockingCallWithCallback(callback);
This is easy to understand, you make some blocking call and when it's done, the callback method is called.
Promise
var promise = function() {
var p = new Promise();
var results = makeSomeBlockingCall();
p.resolve(results);
return p;
}
promise.then(callback);
I tried to do this with as little code as I could, but even without error handling, its longer than the callback example. But let me explain what's going on here. You create a promise object, run some blocking code, then shove the results of that onto the promise and return it. We can chain together functions by using the then, which allows us to call our callback.
So what's the advantage of doing this? There's a lot of extra code and the end result is the same, isn't it? Not quite. The first thing is that you avoid the infamous callback hell. If you wanted to chain using the standard callback way, you'd have something like
makeSomeBlockingCall(function() {
anotherLongCall(function() {
yetAnotherLongCall(function() {
console.log('im in callback hell!')
});
});
});
This happens quite a lot in node, think database work. You open a connection, if it was successful write, after done writing, say you update a file or something.
For the Promise approach, you just have promises that all chain.
promiseForSomeBlockingCall
.then(promiseAnotherLongCall)
.then(promiseYetAnotherLongCall)
.then(function() {
console.log('less callback helly');
});
So there's a slight improvement there in readability. But if the only reason you're using promises is to reduce your callback hellness, you're missing the point of all this. Remember what I said before about imperative versus functional programming? The promises approach does not mutate the arguments. Each promise does something and after it's done, returns a value into the next call in the promise chain. If anyone of them fails, then the chain is broken (this is desired, if you can't connect to the db, you shouldn't write to it).
This is not the case with callbacks. The only way data can get into a callback is via argument. That means that all behavior is done as a result of a side effect (a side effect is when you mutate the argument). You are no longer dealing with objects as values, objects now hold state that mutate over time. This reduces what we can do concurrently as we are now very dependent on the order of method invocations and are extremely sensitive to the state of the variables as they change over time.
So how does this effect you? Well jQuery now has Promises (http://api.jquery.com/promise/) and Deferred objects (http://api.jquery.com/category/deferred-object/). A deferred object is like a promise but has no resolve or reject method (resolve is used to store the results, reject is used to break the chain).
Callbacks are great and easy to understand but let me just say on your next javascript project, you should go ahead and give promises a shot and see what you think.
Tuesday, February 5, 2013
Grep And Less -- In COLOR
I grep a lot; but sometimes, I only have a vague idea of what I'm looking for, so my results can be looong. So I typically pipe it into less and boom, I can page through it. But when I do this, I always lose my coloring :(
But I ran into this neat little trick today:
Before (old way I used to do it):
grep foo * --color | less
Now:
grep foo * --color=always | less -R
Tada! Ok so a little explanation. The color option (turned off by default, which is why we included the flag) actually has three possible values you can assign to it.
1. color=never - Pretty self explanatory
2. color=always - Always include the special control characters to color the text
3. color=auto - Include the special control characters unless you are piping to something or redirecting to a file
So in this case, we need to use color=always.
Now the 'less' part. Most versions of less will not correctly interpret the special control characters. If you run less without -R, you will probably see a lot of added junk in your output. -R or --RAW-CONTROL-CHARS (the longer name is pretty descriptive in what it does) allows less to interpret the special control characters.
Ok that's it. Use it and love it.
But I ran into this neat little trick today:
Before (old way I used to do it):
grep foo * --color | less
Now:
grep foo * --color=always | less -R
Tada! Ok so a little explanation. The color option (turned off by default, which is why we included the flag) actually has three possible values you can assign to it.
1. color=never - Pretty self explanatory
2. color=always - Always include the special control characters to color the text
3. color=auto - Include the special control characters unless you are piping to something or redirecting to a file
So in this case, we need to use color=always.
Now the 'less' part. Most versions of less will not correctly interpret the special control characters. If you run less without -R, you will probably see a lot of added junk in your output. -R or --RAW-CONTROL-CHARS (the longer name is pretty descriptive in what it does) allows less to interpret the special control characters.
Ok that's it. Use it and love it.
Subscribe to:
Posts (Atom)