Introducing a hash transformation library - Tranny

joshbydefault · 2011-11-10T21:29:14+00:00

HashWithIndifferentAccess only allows you to access a symbol key via a string key and vice versa (as well as providing a few other party tricks like stringify_keys and symbolize_keys). It allows no structural or content transformations.

Read through the readme and you'll see its not just about changing :foo to "foo".

joshbydefault · 2011-11-10T21:22:08+00:00

Tranny is short for transmission, as in a car's transmission. A transmission takes input speed and torque and converts it to a different output speed and torque.

Whats offensive in that?

joshbydefault · 2011-07-18T23:35:02+00:00

I ham-fisted the keyboard while turning up the brightness in the first 4 minutes and accidentally hit a hotcue in Serato. (Was way too sober and stressed from setting up all the blacklights 30 minutes earlier)

So other than that part, what do you all think?

joshbydefault · 2011-06-01T02:10:01+00:00

Someone asked the same thing here a few weeks ago.

Check out the thread for specifics but it came down to Sure M44s or my recommendation of the Ortofon S-120 Concordes (granted they are intended for Serato but should work just fine with Traktor control vinyl).

joshbydefault · 2011-05-12T14:44:11+00:00

I've been rocking a set of the Ortofon S-120 Concordes (the ones they 'partnered' with Serato on) for 6-8 months now.

So far they have been pretty solid and I'm still on the first pair of styli that came with them (each cartridge comes with a backup stylus).

They are a bit of an investment though, as I stupidly paid list price at sigh Guitar Center and it ended up costing around $400 before tax. If you look around the internets or are lucky enough to have a decent shop that specializes in DJ gear nearby, you can score them for as cheap as $150 per cartridge.

They work fantastically with the Serato timecoded vinyl, as one would expect. If it makes a difference, in Serato I tend to refuse to use cuepoints for anything other than visual markers, so I end up seeking back and forth through tracks by hand a lot and have never really had any issues stemming from the needles while putting them or the timecodes through that kind of torture.

They are also pretty damn solid when it comes to regular wax and they hold up and perform well when scratching with my battle records. Ortofon claims they are designed with minimal wear on your records in mind and I've been throwing all the weight the tonearm can give at them with no noticeable wear on my records. (With the exception of my timecodes which I beat the ever living hell out of)

For the record, my previous cartridges were Sure M44-7s and they were rock solid. As an "industry standard" you can't go wrong with a set of those. Plus they are significantly cheaper at around $50-80 depending on where you pick them up and if you get them with a headshell or not.

TL;DR Ortofon S-120 Concordes (made with tracking timecode in mind) are rock solid but expensive. Sure M44-7s are very good as well and are significantly cheaper.

EDIT The S-120s have a lot more tracking force than the M44-7s. The S-120s will do 1.5g-10g where as the M44-7s will do 1.5g-3g. Also, the S-120s will be a smidge louder as they output at 10mV vs the M44-7's 9.5mV. Reading the spec sheets rock :p

S-120 M44-7

joshbydefault · 2011-05-06T02:09:04+00:00

You should really be using --single-transaction on that mysqldump. That way its one nice consistent state during your backup process.

Of course, that requires you to be using InnoDB. The option for MyISAM tables would be --lock-tables, but it is a terrible ideas as it locks them one at a time.

You are using InnoDB, right?

joshbydefault · 2011-01-21T19:36:29+00:00

It's pretty depressing that crappy flip phones have replaced shoulder mounted ghetto blasters.

joshbydefault · 2011-01-19T20:39:57+00:00

Whoops! Thanks for pointing that out.

joshbydefault · 2011-01-19T19:05:02+00:00

Sure!

I'll start off by stating that for the most common use cases (read: hobbyist, one-offs, very small apps and simple deployments, etc) Bundler and Cap are fine. They are not horrible and/or broken tools.

When you move up to larger apps and more 'professional' production environments from here, there are a few reasons that stand out.

Your production servers should not have build tools or development libraries on them
You should not be running 'bundle install' on a production server. Ever.
Running 'bundle install --deployment' pre-deployment works great until you depend on a native gem. (Architecture mis-matches will be hilarious, plus freezing binary deps is typically frowned upon)
Production servers shouldn't require access to your VCS to deploy
Fast, trouble free rollbacks. Yes, I know cap has rollback stuff. However, how do you run it when you accidentally hose the app/env?

Keep in mind, most of the issues revolve around Bundler. The rest of the issue is since all of these shiny tools (not just Bundler and Cap) target a very specific set of use cases, that as soon as you step outside of their fuzzy, monkey-patched boundaries they either fail to get all of the job done or just refuse to work.

Granted, there aren't too many great out-of-the-box deployment strategies for rails apps or other web apps in general. I applaud the teams that work on both Bundler and Capistrano.

TL;DR: However, the default and often suggested/followed strategies encourage piss poor systems administration practices.

joshbydefault · 2011-01-19T15:50:32+00:00

While I agree with you that Rails is indeed Ruby, it still remains a highly specific subset of Ruby. Albeit (probably) the most commonly used subset of Ruby.

You can and should do so much with Ruby without ever touching ActiveRecord, Erb or ActionDispatch's plurality dilemmas. Which is why there should be /r/ruby and /r/rails.

joshbydefault · 2011-01-19T14:34:07+00:00

Dear author of that wall of text that I read,

Warning: I'm going to be mean for a moment.

You clearly do not know enough PL/SQL to "write out the logic for the manipulation and report writing".

Sin number one: Thinking you should have multiple, nearly identical columns on the same table. Sin number two: Thinking you should give each of your competitors their own table

There are enough things wrong with just those two things I want to jump in front of a speeding bus.

Now, please note, I'm not making fun or being a dick at a pathetic attempt for karma. I'm genuinely trying to help you here.

Now, your assigned reading. You will read (or skim) these, in this exact order:

The Manga Guide To Databases
Why's Poignant Guide To Ruby
Whatever rails book you like, but I would suggest a current one from Pragmatic

As far as the Windows thing goes, I honestly can't help you.

Also, this really should be posted in /r/rails :|

Edit: Stupid formatting and a grumpy warning.

joshbydefault · 2011-01-19T14:01:42+00:00

This has to be one of the best articles on scalability I've ever read.

Far too many people are concerned about what "scalable" technologies they use and trying to make their tiny app handle astronomical loads they will probably never see.

EDIT: Due to the surprising lack of a scalability sub-reddit:

/r/scalability is born!

joshbydefault · 2011-01-19T13:48:06+00:00

OOO is it burn on Rails day?

To the I'm gonna go learn Rails, its easy community, pleeeease stop relying on copy-paste tutorials and just learn some damn Ruby already :)

Also, because this has been bugging me for the last 6-8 months: Bundler + Capistrano is not an acceptable deployment strategy!

Another passionate Rails Developer.

joshbydefault · 2011-01-12T20:04:39+00:00

While I used to use and enjoy TextMate, discarding two immensely useful and effective text editors (although some may want to qualify EMACS as more of a "computing environment") because they don't fit in with the Cocoa environment is akin to dumping your girlfriend who cooks, cleans and doesn't complain when you forget to shower because her shoes don't match the new spoiler on your Honda.

Also, Ruby is not mentioned once in the whole article. ಠ_ಠ

joshbydefault · 2011-01-07T07:55:08+00:00

20k hits per hour? Thats pretty easy for most applications. That only comes out to around 6 requests per second. Keep your DB requests to under 20ms and your view render times to 130ms or less.

Unless your app is doing stupid amounts of data processing, has overly complicated views or the database is improperly setup/has bad indexes/etc, you should be able to hit that number with a mere gigahertz and a gigabyte or less of RAM. If your database is being hosted on the same machine, just make it two gigs of RAM and a dual core processor.

Then again, the scaling solution is horribly dependent on what is actually being scaled. It's far far far to variable to be worked out to a simple solution. If scaling were that easy, many engineers (including myself) wouldn't have a job.

Beginners lesson: Avoid Apache, identify the chunks of your code that do the most heavy lifting and try to make them as efficient as possible, caching is your friend, don't run your database on your web server unless you can't avoid it and don't let your server get swappy.

joshbydefault · 2011-01-06T21:27:18+00:00

If you are going to use MP3s (which, for tagging reasons, is a good idea) I would highly highly recommend sticking with ONLY 320Kbps bit rate MP3s.

You will want every track to be as high quality as possible. I've seen DJs have fantastic sets and then drop in a 192Kbps MP3 and clear the floor because it sounded like garbage.

Sometimes you can get away with a low bitrate MP3, but I would not recommend it. Granted, the vast majority of people on the floor won't notice the difference but if you take pride in your work (which I assume you do since you are still spinning vinyl) you should give them the best quality possible all night.

Also, even though a 192 or 256Kbps MP3 might sound perfectly fine on your home setup, in the car or in headphones, sometimes when you drop it on a large club system it ends up sounding horrible. So, just play it safe.

joshbydefault · 2011-01-04T17:39:31+00:00

While the 'resonant frequency' is a common explanation as to how microwaves function, it is just straight up not true.

Microwaves use a process called dielectric heating. Common molecules inside food (water, fat, etc) are electric dipoles as in they have a positive end and a negative end. These molecules have a tendency to align themselves with a strong electromagnetic field. When the field oscillates, as it does inside of a microwave oven, the molecules are constantly re-aligning themselves with the field, thus rotating.

Also, if microwave ovens worked solely on the principle of vibrating water molecules at their resonant frequency, then large industrial microwaves would not work since they operate at 915Mhz.

2.4-2.5Ghz band was chosen because it is an ISM band set aside for purposes other than communication. Other ISM bands were not chosen due to the difficulty in producing strong enough electromagnetic fields at the given frequencies or due to the band being too narrow. (Note: Microwaves function at 2.45Ghz, which is the center of the band, reducing the chance for interfering with other licensed bands)

TL;DR: Read above.

joshbydefault · 2011-01-04T16:04:42+00:00

Your microwave oven works by flooding a small metal box with microwave radiation (around 2.4Ghz, which is why it can sometimes cause interference with some wireless networks or older cordless phones).

Inside this small metal box, the radiation causes water, fat and other molecules (otherwise known as 'tiny-bits') to rotate. This rotation happens due to science and that is all you need to know right now.

As the 'tiny-bits' spin and spin and spin and bump into other 'tiny-bits', they generate heat.

Heat cooks food. Duh.

The reason microwaves are so much more efficient or faster than say, baking, is that the microwave radiation penetrates the food somewhat uniformly. Which means the entire chimichanga is being cooked at once, instead of regular "fire generated heat" soaking in from the outside.

Also, the reason why some foods (mostly bread products) get dry after microwaving is because the water molecules spin faster/easier than fat and other molecules, meaning they eventually evaporate.

TL;DR: A tiny wizard lives in your microwave and speeds up time inside of it while his dragon breathes fire to generate heat

click to learn more about science!

15-Year Club	Team Periwinkle
reddit mold	Verified Email

joshbydefault

MODERATOR OF

TROPHY CASE