@_devbob I'm an Engineer implementing awesome tools for the Data Science team at @Ahalogy. These are my musings. Some are related to free books I'm writing.
Get Around Using S3 for pg_dump Restores in Postgresql
I recently had to restore from a dump of a Postgres server for an application I was building. However, S3 (the preferred provider of files for heroku) kept timing out when I would upload this dump (it was around 90mb). So, I went to dropbox, thinking its direct link (in the format of https://www.dropbox.com/you/my.dump) would work in the Heroku command.
This, however, was not true. I was getting an error. Specifically, one saying I was trying to upload HTML content upon reading my logs. So, I figured this out. Instead of running
Obviously I changed my UID and such, but you get the picture. So there you have it, now you can run a restore from that dump clean using dropbox over s3.
As you may know if you are one of the folks who frequent this blog, I am writing two free and open source books. They are Clojure: From Zero to Deploy and A Fun Introduction to Meteor.js.
Amtrak recently announced a pilot program where writers can take long round trips for the purpose of writing the entire time on the train. I had actually already planned to do this from Cincinnati to LA on my own. I am hoping maybe they'll cut me in on this awesome deal and I can get the cheaper/freebie ride.
Either way I'll be doing it on my own come April, or maybe sooner if they get back to me. Feel free to tweet this out or share and hopefully I can get their attention. I'd love to push open source/free educational content and market for the open source community in general to get the word out on projects like mine.
var alphabet = "abcdefghijklmnopqrstuvwxyz"; ); var query = from a in alphabet from b in alphabet from c in alphabet select "" + a + b + c; foreach (var item in query) { Console.WriteLine(item); }
However, you're an awesome developer. The apple of Lisp's eye. The super-productive machine that intakes caffeine and outputs software. Sweet. You already are testing, then. Well lets make it even easier to test. The specific pieces we will be using give us some hella cool stuff to work with. We will be able to:
Have pages live reload anytime we make a change to the styling or view
Have our specs run automatically when changes and/or committed
Allow a tag to run only one test or a specific scattered group of them through the codebase for faster runs
Have our stylization forced upon us while coding it live, resulting in better Ruby
Not even have to try much to accomplish all of this
Sounds awesome, right? Meteor.js esque live reloads, automatic specs running, focus on specific ones so the suite doesn't take forever to give you your precious green dots, and we will be writing prettier, proper Ruby the entire time.
Lets set it up
I'm sure you've heard of Guard. Or, I hope you have. If not, welcome to some awesome test driven development! Now, here is our gross overview of what needs done:
procure the "guard-rspec" "guard-cucumber" "guard-livereload" "rubocop" "precommit-hook" "guard-focus" and "guard-rubocop" gems.
Configure these slick, sexy bastards to work on our side instead of wasting away with the Sith if they're untouched on GitHub too long
Proceed to love life and look totally badass when all this shit just starts working.
Lets start with Guard. First, we need to install it. Throw 'guard-rspec' and 'guard-cucumber' in your development group. Now, to set it up run
bundle
bundle exec guard init
Once this finishes we have an empty guardfile. Here is a gist of my preferred boilerplate guardfile:
https://gist.github.com/rhgraysonii/8940236
Now, lets get live reload working so we not only have automatic tests but automatic browser updating. Add in this snippet before the end of your guardfile:
guard 'livereload' do
watch(%r{app/views/.+\.(erb|haml|slim)$})
watch(%r{app/helpers/.+\.rb})
watch(%r{public/.+\.(css|js|html)})
watch(%r{config/locales/.+\.yml})
# Rails Assets Pipeline
watch(%r{(app|vendor)(/assets/\w+/(.+\.(css|js|html))).*}) { |m| "/assets/# {m[3]}" }
end
Bam! Our page will now reload live after bundling and restarting guard. Now, what about forcing us to write in proper syntax! lets modify our gemfile again and in our development group place:
gem 'rubocop'
gem 'guard-rubocop'
Now when we run
bundle
bundle exec guard init rubocop
After bundling, we will have our guardfile modified to force us to fix our improperly styled ruby on file-save!
Next lets dive into focusing tests, and pre-commit hooks. The last pieces to become even more hyper productive with our testing, again putting them in development's group:
gem 'guard-focus'
gem 'precommit-hook'
Lets run bundle. After that, we run
bundle exec guard init focus
and now any test rspec or cucumber flagged with :focus before their do will run alone and nothing else in the file will unless also tagged.
To set up our precommit hook we just need to run one simple command and set up a .yml file. Easy! Lets add it in our development group.
gem 'precommit-hook'
Now we just need to bundle and run
precommit install
Bam! Now we have a .yml file to worry about. All the options are listed in the github repo that is linked at the end, but here is a gist of mine:
So theres that. Less than 20 minutes and your testing suite is now about 1000 times more efficient and useful, AND you're forced to write prettier code before you commit it and all you need to do is run:
Ember is a wonderful little frontend framework. It is simple to integrate with rails, offers plug and play ease of use, and in general is eloquently written code (outside of handlebars, which I personally use emblem over, but that is a talk for another day). Ember, like Ruby, also has a metric buttfudgeton of built in methods and actions that allow you to do things easily.
The Ember docs reference the error and loading substates directly, but I have not seen many tutorials that dive into the topic. The concept, however, is very easily implemented. The docs go over it here if you would like to read in directly, but here is a simple tutorial that will go over how to do it in rails and a standard ember app both.
How it works
When Ember is switching states using one of it's controllers, no matter what the controller currently being used a promise is generated in the exchange. If this promise takes too long to have a response made to it, Ember has a built in loading substate. What this allows is the implementation of a simple loading template that will automatically be rendered. Awesome, right? Plug and play loading screen that can be implemented with the addition of one file. '
Making it work in vanilla Ember apps
First, you will need to find the file you want the template to be in, or if you are going dead simple throw it in app.js. Here is what we will need to write:
<script type="text/x-handlebars" data-template-name="loading"> <div>Throw your message or loader here</div> </script>
Bam. That east. Now you have a loader whenever a promise being thrown between pages is taking too long to load. It is equally simple to implement in Rails. In your templates folder you should throw in a loading.emblem, loading.slim, or loading.html.erb, whatever fits what you are using for the project. This example is in emblem:
#loading
Boom, now its functional. This plug and play loading screen t0t3z rulz0rz. It seriously cant get simpler. Check out some of the example loaders I forked and toyed with on codepen for inspiration!
I honestly can't think of a way to ask for something better. It is so plug and play platforms as massive as Github and as small as Penflip have been launched with it and flourish. Yes, you need to scale it eventually, no it does not do this perfectly. But I'll be damned if it isn't the most eloquent and simple way to prototype an application that can handle being production. A quick look at many blogs, twitter, trends in startups, and other general indicators of the technical worlds happenings will quickly reveal one thing: JavaScript is really popular. Like, REALLY popular right now. Hipster chic in Portland level popular.
What the hell does all this mean anyways?
Well, for one thing. I hope you know JavaScript. Any web developer who previously had been in another stack has almost definitely felt its slow, trickling grasp come there way. And not just the jQuery. Redoing UI's in JavaScript frontend MVC's, building entire applications on top of a platform like Firebase that allow you to have persistence without a true DB. Many have danced, a few have sung, and just about as many probably whined. Programmers have strong opinions. A language you cannot properly handle date and time without a library being added extraneously is quite impractical, or even insane to most; though it is quite doable to make JS eloquent. Especially with tools like CoffeeScript (which I refuse to refer to as its own language. But we won't even have the debate). So what's right? What's wrong? What's going to happen? I think "a lot" is the proper response.
Well chances are, we'll all just keep writing code however we damn well please
However, I do see one very interesting potential scenario. I have played with backbone.js, angular.js, meteor.js, and ember.js. They all offer interesting tidbits, functionality, and use cases. However, overall, it seems as if there are two potential routes of possibility for this entire situation; and one of them is far more interesting than the other.
One:
These frameworks continue to duke it out, slowly iron out their kinks, and eventually all are reasonable tools for a given solution. Be it Backbone's freedom, Angular's creativity, Meteor's live data, or Ember's eloquence. Rails continues to be the big kid in the room and thinks back to 2006 with an idle smile, head tilted every so slightly, enjoying watching the show. This is boring. But very possible.
Two:
Ruby on Rails adopts an official frontend MVC framework. The matter of using Rails as an API and concentrating on JavaScript for the frontend is a great structure. The capabilities it produces and eloquence it provides are very Ruby-Tastic even to an old school Ruby fiend, as well as a new developer.
Which framework does Rails take up?
In my opinion there is only one answer to this. It is Ember.
IT JUST HIT 1.0 MONTHS AGO YOURE AN IDIOT. RAPID CHANGE IN RUBY ON RAILS HAPPENS BUT IT WOULD NEVER FORCE A FRONTEND JAVASCRIPT MVC FRAMEWORK ON SOMEONE.
There, got it out of your system. Now to move on. Rails already has made a move near equally radical. The inclusion of CoffeeScript as a Rails core package was not only drastic, but changed the tide of the community. The evolution of the language has grown to the point where one can now be find job postings for a CoffeeScript developer. This would have been unthinkable in its earlier days.
DHH is an opinionated man. He is also very, very good at writing software. The utility that a simple integration of Ember.js provides to a Rails project is undeniable. It need not be forced. It's a tool to bust out when needed. But Ember.js is the only framework that even comes close to the eloquence of pure Ruby. It is convention over configuration. It is simple to write, and it runs fast. You can pick it up in a weekend with reasonable ease. It offers more than any other framework of its type.
This is just food for thought. I'm not saying I'm calling it right now. But I definitely could see it doing some amazing things for the community. Think of the rapid growth of what it could do and how well it does it just being pushed to the limit by one of the largest and most active groups of devs in the world.
I've been a *REAL* Developer since 2pm on Friday...These are my initial thoughts.
I still feel like I don't know what I'm doing. But I do know I absolutely love it.
That, of course, is not to say I don't feel qualified. I think this is a feeling essential to exist in a good developer. You can never be done. Your product is never good enough. Your code is never good enough. Hubris leads to things such as Windows ME.
*shudder*'
So how in the hell did I actually end up here?
Well, it started with Epicodus. When I decided to drop out of college and go for a boot camp I had a very clear line of reasoning:
I was in college and taking a physics curriculum. I had a hobby of refusing to even show up for any class that was not math or physics. Smart guy right? I quickly realized I was essentially throwing away large sums of money, and only wanted to continue in academia and end up with a PhD then shrug my shoulders and hope being a "doctor of physics" would pay my bills or something. This was very questionable on a long term economic basis. Sitcom physicists such as Sheldon Cooper can live in the Bay Area in swanky apartments, but I feel this is a manifestation of a friendly set being conducive to a television show being well received rather than an accurate socioeconomic reflection of real estate pricing in SF.
Oh wait, I've always been a hobbyist programmer for near a decade, and I just haven't ever actually "gotten" it enough to make full blown applications. Just scripts, some web pages, etc. I applied to ten programming bootcamps. I got into 8. I chose Epicodus because it seemed like Michael was an amazing teacher and it was the longest of any program I had seen.
Epicodus was the most rewarding thing I have ever done. However, this is not to say that it got me the job I have. If there is one thing I have seen about the developer boot camps that have sprung up all over, its that so many of them glorify the money. 12 WEEKS MAKE 100K A YEAR. This is a general form of advertising many newer ones have taken. However, it is far from accurate. If you want to be a GOOD developer, have the humbleness to realize that NO school or bootcamp can take 12 weeks and automatically make you worth 6 figures. However, it can definitely plant the seed that results in your new, extraordinary, interesting, fun, and useful skill. You can take 1's and 0's and make things. The concept of this still sends shivers down my spine. From a purely economic standpoint software engineering is the ultimate way to "create". The overhead is a machine that can turn on. A $50 7 year old dell laptop will run ubuntu and allow you to build a Rails app. There is essentially no barrier to entry. Show enthusiasm and someone will help you get into the world.
Being a developer is an artful craft. 4 months at 40 hours a week is enough to incubate you as a developer. However, you don't come out at the end and have a magical developer cape that you wear with your developer underwear that runs lisp code to put on your pants. You have to invest. I started two free books: A Fun Introduction to Meteor.js and Clojure: From Zero to Deploy. I found a startup I believed in and volunteered my time to help out because it was 2 cofounders living off savings building an amazing product. I got on twitter and hacker news and shared all these things and tried to find whatever I could.
The effort obviously paid off. I don't think I have ever been treated nicer by humans than the folks at Ahalogy when I came here. This is roughly how day 1 went:
1. Arrive in Cincinnati to office.
2. Meet staff, office dog, get a beer from the kegerator, check out what everyone's working on
3. Get sent to the apple store to get myself and the other new dev some new macbook pros
4. Come back and set up dev environment
5. Go to my prefurnished, paid for, beautiful apartment they were nice enough to put me up in until I find a place around here
Sounds perfect, right?
It was. Seriously. For a first day in an office, I do not know how you do it better. I've never been more excited to work. We're sitting on so much data it gets me immensely turned on just to think about playing with it, building awesome tools, writing tests, and just hacking away. It's wonderful. So, be a developer guys. It's awesome. Just keep your eyes on the prize: knowledge. Always be learning. Being a developer rocks because you can learn something new every day for 30 years if you want to in the same field. If you have that fire you'll succeed.
I have always been helplessly intrigued by the man known as Richard Feynman. My initial foray into this curious character's work, like many, was one I will never forget. It was 8th grade, I was just getting into 'tech' culture, my first attempts at running Linux were recently successful having gotten Ubuntu 6.06 to run on my home desktop (I requested the free discs online, which to this day is one of the best favors anyone has done me. But that's another story), and TechTV had not yet been ruined by Comcast. It was a wonderful time for me, fantasizing about WarSpying, WarDriving, hacking Windows Components into a Mac Mini after Kevin Rose did the same, and other projects of the 'hacker' ethos that took over my rebellious minds capabilities and lack of stimuli from other sources. On a program known as the Screen Savers, for a reason I can't remember, they referenced a problem of physics:
A fisherman rowing his boat on a very small lake throws his anchor into the water. Does the water level of the lake rise, fall, or stay the same?
This is a classical example of a problem from Feynman's Lectures on Physics and, as many of you know, to a teen just getting into science, technology, and the surrounding world, the answer to this problem is quite fascinating, and at first glance, unintuitive. The water level falls.
But once this introduction came, I was a fiend to find out anything I could from this guy's lectures. I began to read every single one. Now what does Feynman have to do with TDD, programming, or anything relevant to these tangentially?
His Approach.
Big Problems. Simple Answers.
In Danny Hillis's essay about working with Feynman over a Summer at his company Thinking Machines, he described this as the approach he would take:
"For Richard, figuring out these problems was a kind of a game. He always started by asking very basic questions like, "What is the simplest example?" or "How can you tell if the answer is right?" He asked questions until he reduced the problem to some essential puzzle that he thought he would be able to solve."[0]
This method is clearly effective. The man is a Nobel Laureate, has solved some of the hardest problems that quantum physics presented the world at the time, and contributed to countless other industries, projects, and fields of science using it. There is something to be said for simplicity. Breaking a large problem into a simple one is exactly what any programmer does when approaching it from the beginning. After all, a computer lacks the context our lovely network of neurons globbed together inside our skulls provide us.
Sometimes It Isn't Fun
Sometimes TDD is a pain. You've got an idea. It's sparked. You want to get in the console and experiment, play in IDLE, whatever. You get distracted and soon a class has been authored in it's entirety. Oops. Many developers now go back and write the tests, some don't. But there is a piece that comes to be missing at times when this approach is taken. You may have broken down many of the finer points to their simplest piece, but by actually breaking it down and going piece by piece, in a series of failing tests, almost every time had this route been taken there would be more exceptions, possibilities for failure, or gross oversights caught.
Feynman dealt with this too. Taking the complex calculus that powers something as simple as a basic Feynman Diagram of an electron and positron colliding to emit a photon would take several hours of lessons at a bare minimum to teach someone with an understanding of calculus even a remote idea of what is going on. Were talking about going from this:
To this:
However, by breaking it into these "simplest ways something works or happens" throughout the entire process, once he completes this he was able to create what is debatably the most intuitive methods of illustrating complex physics in the modern day, making it accessible to any elementary school child with a pencil, paper, and a teacher who understands the diagrams principles as well.
TDD: Do Something Somewhat Annoying to Create Something Beautiful
Well tested code speaks. A new developer knows what will happen, where it will happen, and what he is getting into. Customers do not see these tests, but their services generally are quite reliable and things won't implode near as often. Everyone wins.
I guess my overarching point here is this:
Some moments I would rather fight a reasonably large pack of wolves than write another unit test. However, for the greater good I find myself defeating this distaste and just doing it. Correlation may not imply causation, but I have found that I have become a much better developer the more I do this. It has forced me to learn to fully understand what every move and change I make is doing, and what it impacts. Unforeseen side effects are caught, exceptions handled, and I have far fewer "dear lord, how will I debug this" moments.
So, anyways, keep on testing guys. It's chicken soup for the coder's soul.
If you enjoyed this, feel free to follow me on Twitter
As Epicodus wound down I have found little time to continue additions to the book, though other contributions have been made and merge requests accepted. However, I am excited to announce that in the next two hours I will finally be in humble, boring, simple Ohio, and have ample time to continue onward. I am shooting to have the chapters up to completing a trivial application such as a To Do list complete within 2 weeks.
Today, I was encountered with a somewhat strange situation.
A good friend and coworker of mine, Jason Rodriguez (http://jasonrodriguez.net/) woke up this morning to see he had his first github repo forking ever occur. Exciting, right?!
Well, it turns out that the repo was forked...but then this curious character decided that he should not only copypasta the entirety of the code from several other of jason's repos and load them in his own, called "Javascripts", he also immediately opened a personal domain page in which he stole the entire theme from Jason's personal site (referenced above) and didn't even change the filler text other than subbing out his name for Jason's.
This is just wrong. The entire point of open source is to contribute as a group and grow and gain. If you want a personal page there are 10,000 MIT licensed open templates you could use for free.
If you absolutely need to build a basic rails app Michael Hartl's tutorial will give you all you need.
If you want to fake being a developer of some skill level X to get into a coding bootcamp, you should stop writing code.
I just found it quite strange someone would even attempt this. What is being gained? You cannot fake being a developer. It isn't possible.
Here is this guy's github.
https://github.com/ACMotanya?tab=repositories
javascripting, and youtube TV are both direct copies of what is on Jason's github.
I just have to ask, why?
The tech community prides itself on ingenuity, collaboration, hard work, and forward thinking. This is the opposite of all those things.
So, I guess my point here is really just, "Don't do this." I found it very personally offensive that someone would pull such a ruse.
On Motivation, Open Design, Open Source, and Just Doing It.
Howdy.
I figure a little background may give light to the inspirations, goals, and larger picture ideas of this project. So we're going to have a fun little write up on that topic here.
On Why Bother
I've always been the guy who writes. A lot. Personally I feel a book or other piece of anything that could be roughly interpolated as "art" carries a certain weight that the medium of scientific accomplishment, understanding, and contribution cannot.
If a scientist in Rome and a scientist in Canada both begin vigorous research of the effects of the Cashmir Force they will both yield the same findings. The papers may contain different examples, wording, and other minutia; but the discovery, the mathematical representation of fact in our larger world is a piece that will be universally the same with its input and output for this event.
This is not the case with a book, a film, or a picture. Simply put, a piece of the self ends up in these pieces that cannot be attained in a discovery scientific. I feel this carries a value that is inherently good that I have always sought after personally.
I also love teaching, and experiment. I wanted to do this as a means to teach others while I teach myself (a doubly selfish endeavor due to my own interests, but one with benefits nonetheless.) in order to offer gains in both plains. I also needed a good excuse to use Penflip. That service is just astounding. I cannot believe someone had not done it before.
Penflip
Open source software has been a passion of mine ever since I read The Cathedral and the Bazaar. The Entire concept of the platform is wonderful and does nothing but allow technology as a whole to advance even further. The existence of platforms on the level we have in Open Source today speaks for itself. Android, the Linux kernel as a whole, the myriad of projects businesses and people use every single day that have their code public on Github or Sourceforge. It is astounding.
I wanted to be completely transparent with this book. I have no means to profit from it. I just want to learn myself and help others do the exact same thing. It's a labor of love. A disclaimer: I will take a beer
Buy me one?
On Just Doing It
This project is largely an exit from my comfort zone. Though a man in love with mathematics I find new and interesting challenges every day broaching the topics needed to conquer the process that is writing this book. I find I generally have a ton of pet projects. I also find I am guilty of abandoning many of them.
That is not, however, to say that they were projects not worth pursuing. I was just being lazy. I made this public and collaborative to pressure myself to work harder and faster and to make sure that I was absolutely outputting the best content possible in the event someone ended up actually reading it.
Anywho, I hope this may inspire someone else to contribute or start a project of their own. I sure know that as soon as I open up penflip I just get more and more motivated.
Cheers,
Bobby
The book
Wandering Geek @rhgraysonii - Tumblr Blog | Tumgag
gracieabrams
amandla
areudirty
stormborns
origamiaround
turnnoffyourmind