Screen
run `screen`
detach from screen using ctrl + a and ctrl + d
`screen -list` to see all screens
`screen -D -r ‘1234.name_of_screen’` to reattach to the screen
Alisa U Zemlji Chuda
Aqua Utopia|海の底で記憶を紡ぐ

JBB: An Artblog!
DEAR READER
Game of Thrones Daily
No title available
No title available

izzy's playlists!
"I'm Dorothy Gale from Kansas"

pixel skylines
dirt enthusiast
Three Goblin Art
Sweet Seals For You, Always

Discoholic 🪩
Cosmic Funnies
occasionally subtle

tannertan36

PR's Tumblrdome
hello vonnie
🪼

seen from Spain

seen from United States
seen from Guernsey
seen from United States

seen from United States
seen from Romania
seen from Netherlands

seen from United States
seen from United States

seen from Malaysia
seen from United States

seen from United States
seen from Indonesia
seen from United States

seen from United States
seen from United States

seen from Guernsey
seen from United States
seen from Brazil
seen from France
@juliethethrill
Screen
run `screen`
detach from screen using ctrl + a and ctrl + d
`screen -list` to see all screens
`screen -D -r ‘1234.name_of_screen’` to reattach to the screen
Our answer to Shark Week.
Starting Resque Workers
Say you need to send out an email campaign ASAP to a gagillion users and the time window when people generally respond to emails is quickly shrinking.
What do you do? Start a Resque worker for each campaign of 10K users or so instead of just letting the campaigns send on one process for hours.
Log onto the machine where you want the workers to run and use this command:
bundle exec env RAILS_ENV=production COUNT=4 QUEUE=campaign_urgent rake environment resque:workers
COUNT is the number of workers you want to start. When using COUNT, be sure to use the rake task "resque:workers" instead of "resque:work"
To start a single resque worker, use this command:
bundle exec env RAILS_ENV=production QUEUE=campaign_urgent rake environment resque:work
When doing this, I recommend using screen so that if you want to get out of your terminal window while the jobs are running your workers won't die. When you log onto the machine for the workers,
- run `screen`
- start your worker(s) using the above commands
- detach from screen using ctrl + a and ctrl + d
Define your Job to run on the new fancy workers
class Jobs::SendUrgentCampaignEmail @queue = :campaign_urgent def self.perform(campaign_id) # mail out your campaign end end
It is important that the @queue variable in the job you define matches the QUEUE that you set up in the resque:workers task. This is how the worker knows to grab this job. Now that you have your workers started up, queue up a job. In Console on the machine with the workers, run:
Resque.enqueue(Jobs::SendUrgentCampaignEmail, campaign.id)
When your jobs are all done, re-attach to screen and kill your excess workers
`screen -list` to see all screens
`screen -D -r '1234.name_of_screen'` to reattach to the screen
In a console, remove the urgent queue you made for this task
>> Resque.queues
>> queue_name = "campaign_urgent"
>> Resque.remove_queue(queue_name)
Does this count as annoying?
There is a tumblr dedicated to gifs related to Despicable Me. Fantastic discovery.
Speaking at Goruco 2013
A House of Cards: The Perils of Maintaining a 7-Year-Old Codebase.
This talk was a lot of fun about my experience starting at StreetEasy.com and what it was like to be thrown into a giant codebase coming from only controlled university programming exercises and small freelance projects.
Watch the video here!
"With RoR, often the focus is on how easy it is to build an application from the ground up. But, there is a whole different set of challenges when working on a mature application. This talk will discuss the issues discovered when peeling back the layers of a 7-year-old pile of code. In the beginning, the question isn’t “How do I build this,” but more like “Where does this go” or “Where is this bug coming from.” I will discuss the sometimes-unintended consequences of introducing new features, tracking down and fixing ancient bugs, estimating the time a new feature will take to build given the many other peculiar surprises you will uncover, and finally how not to worry about the inevitable day when you will break everything. The audience will hear from a developer who works with old code every day and get tips to make their future selves and successors less confused, more productive, and less unintentionally destructive."
Git Hooks
It would be great if we were notified when to run bundle install and/or migrate the database!
We are going to use the post-merge git hook, which is called after you pull from the repository.
In the root of your project directory, cd to .git/hooks.
$ touch post-merge <-- create the post-merge hook file
$ chmod +x post-merge <-- this makes the file executable
Open the post-merge file you just created (ex: $ sublime post-merge OR $ vi post-merge)
Add this to the post-merge file .. this handy script will let you know if there are any gemfile changes or any new migrations for you to run after you pull.
Terminal Aliases
I have been web programming for how many years now and have no aliases to speak of? What is going on here?
Go to your app directory and start the server
Add the following to ~/.bash_profile:
alias myapp="cd path_to_app_directory && rails s"
(ie: alias myapp="cd Documents/my_app && rails s")
Then in a new terminal window (don't forget to restart terminal or open a new window): $ myapp
Should automatically go into the correct directory and start the server!
Tired of going to http://localhost:3000 in chrome all the time?
Add the following to ~/.bash_profile:
alias localhost="/usr/bin/open -a '/Applications/Google Chrome.app' 'http://localhost:3000'"
Then in a new terminal window: $ localhost
Should automatically open Chrome to localhost:3000.
W00t!
Practical Object-Oriented Design in Ruby, by Sandi Metz
Great read!
As a programmer with 1 year in the "real world" under her belt, I've learned quite a few things.
In school, I never really understood the difficulties of maintaining codebases, because I never had to maintain anything that I or anyone else wrote. Nearly 1 year at StreetEasy has taught me the pains and joys of maintaining someone else's code (written circa 2005).
I learned about "OOP" in school but never really had the chance to put it into practice or see it in action on a large scale. After seeing the results of 7-8 years of building an application, I have started to notice which parts of our codebase are easy to maintain and which parts are more challenging/complicated.
Sandi Metz's book on POODR was a great explanation of why I like some parts of our code and why I don't like other parts. The examples showed what could go wrong in various scenarios and what could go well. I could start to understand the consequences of the various design decisions made in our code long ago.
OOP makes a lot more sense with some context. When I learned about it in school, I had nothing to compare my designs with, and had no idea how they would fare when requirements changed or when years had gone by.
There is still a lot of learning to do, but maintaining other people's code is a great way to get context and see farther down the road of various design decisions.
Sandi Metz's book has filled in some gaps in my knowledge, connecting what I already knew about OOP with the experiences I have had wandering (and breaking/building onto) StreetEasy's app.
See what I'm reading next.
Programming
Styling Email Templates
There are few things more tedious than styling email templates to look good in many email clients. Here are a few things I've learned from my incredibly pleasant work styling emails.
1) This is a handy post comparing the mail clients' support of various CSS tools.
3) Always use inline styles. This tool does a great job.
4) Viewing the original email source is the easiest way to see the interpreted styles by the email client. They won't always match the styles you wrote!
5) The style attribute height changes to min-height in gmail, causing things to not look right. ie: <div style="height:50px;> will be <div style="min-height:50px"> in gmail. Use <div style="max-height:50px;"> instead!
6) Line-height has often been the culprit of style mismatching across mail clients. It is sometimes added automatically by the client, so by actually setting it, you can be sure that it will be set to the value you want.
7) TABLES EVERYWHERE! Nested tables, tables inside of tables, tables with only one row.. use tables for everything. They are the most stable to work with in the mail clients.
8) These blank MailChimp templates can be a really helpful starting point, although they often need tweaking to work in all the mail clients. You will also need to run the templates through the automatic inline styler and then tweak from there (see point #2).
Good luck! Patience and/or a glass of wine can both be very helpful in the email styling process.
`whoami`
Julie "the thrill" Gill
Ruby on Rails Developer at StreetEasy.com
Paleo enthusiast
NYC-based, San Diego-born
Crosstitcher
Lover of Ballet
Pace University Alum with a CS degree, with minors in Digital Art and Dance
Huge fan of animated gifts. Like these
The Path to Awesome
Getting started on this blog is partly inspired by Seth Godin's Overcoming the impossibility of amazing:
If you set your bar at "amazing," it's awfully difficult to start.
Your first paragraph, sketch, formula, sample or concept isn't going to be amazing. Your tenth one might not be either.
Confronted with the gap between your vision of perfect and the reality of what you've created, the easiest path is no path. Shrug. Admit defeat. Hit delete.
One more reason to follow someone else and wait for instructions.
Of course, the only path to amazing runs directly through not-yet-amazing. But not-yet-amazing is a great place to start, because that's where you are. For now.
There's a big difference between not settling and not starting.
-Seth Godin
This is me, starting. Starting at average with plans of continuing on the journey to great/awesome!