AlexMcP

None were particularly common, mostly hapax legomena: typos and wishful thinking like vertical-float and other things like that

I thought long and hard about trying to identify preprocessor usage reliably because that is a super interesting piece of data, but nothing stuck out as a smoking gun. Sequentially increasing selectors

  tr

  tr td

  tr td a

  tr {
    td {
      a {

I mostly ignored by-domain grouping in my queries, but there is a host of analysis you could do that would get into the modeling portion of data science, teasing our correlation and trying to find 'groups' or styles' of CSS that is written on a site. I had only so much time ;-)

I also did a web perf report that is not fully edited or ready for consumption, but does not that 54% of sites I ran Google Page Speed Insights against didn't compress all of their CSS assets. (Same sample of domains)

  select count(*) from property 
  where value similar to '%!important%'

  => 177119

That's what I saw when I spot checked it. Explained both pseudo selector and content prevalence.

Hey OP here, I still have the data around if anyone has further questions to investigate.

Awesome! Thanks for the knowledge

What sort of method would be used to cluster those, statistically speaking? Like, given a data set like that, how would you determine if the distribution is multi-modal or unimodal?

Surely the idea of a one-off crowd sourced mini incubator is at least a little interesting to someone who writes|plans|sells software.

Immediate reactions from me include "Should my company get on board with something like this?", "I wonder what the equity split is like", "Could there be a platform for voting up ideas to work on based on customer validation?", "Should I build that platform to bubble up ideas with a verifiable userbase?"

Site's back up, we scaled up some dynos. Thanks Heroku :-)

I use it outside of a Rails project when I don't have the asset pipeline available in my tool chain. It gives me the scalpel to define exactly what happens to my code and files vs. a one-size-fits-all option like LiveReload or Brunch where I need to match a specific filesystem layout.

I think it's important to note that if this code never grows or changes, then this refactor is totally unnecessary. It DOES add code, and it DOES almost over-decompose the structure.

The payoff, however, is if more features or behaviors were in the pipeline (and when aren't they?). This really sets you up to gracefully manage more complexity by having sensical places to put more code, instead of writing a few more $(document).ready callbacks to ship something on time.

Backbone.js might not be the right tool for the contrived example, but I've come to expect a sacrifice of real-world applicability for smaller, digestible chunks. That the synthesis is up to you is ok, I think.

Hmm, maybe I'll get around to looking at his vimrc and seeing what proportion of the settings are in the scraped files. I bet I could further validate your cargo-cult hypothesis.

This is the main issue with trying to catalogue event handlers. Backbone.js, and savvy jQuery developers won't use bind for any sort of dynamic pages, because it's too hard to track handlers and make sure they're rebound properly as the DOM updates. The best solution is to use .on, which generally (argument specific) will set up a listener on a PARENT element of the selector you've put in.

.live() .delegate() and (usually) .on() will leave the handler on a parent node, making sniffing out all active handlers an expensive DOM-walking task.

I have 2 repos on my github account:

https://github.com/alexmcpherson

One is a scaffolded rails app with interesting folders /scraper and /files

And the other is the microsite that was linked in the parent post

What is it purported to do vs. what does it actually do?

I'll work on combining these; as a vim neophyte I wasn't totally sure which ones might overlap. At least I got color|colorscheme.

Thanks!

Did this for fun mostly to test out casper.js (it's nice!)

I'd welcome any feedback on how to better present interesting data, or answer any questions. Thanks!

Incidentally, it doesn't "produce" any markup. There are form generators for at least Rails available, but generally you do whatever to get the markup to conform to their expected structure.

That being said my experience is heavy on the forms portion of their styling, and there is an extraneous div.input wrapped around each element, but you'd often do something like that on your own anyhow.

Generally: Good Stuff

I was in the same boat. I graduated from a liberal arts college with a degree that no one has ever asked about. After lots of non-profit work after school I was tasked with 'updating the website' one day. Cut to 3 years and $100+ in library fines later and I've been the lead developer on Fortune 50 websites and now work for for a 'rent a Rails shop' company. Here's the advice:

Learn how to interview well. Knowing what github is, having actually launched a site, and wrangling some freelance work together puts you ahead of 90% of the people I worked with at my Big Co. job, you just need to be able to prove it and convince people of it. The competition for most positions consists of bored CS grads from Java schools who never learned how to use version control and for whom programming is just a job. You have passion it appears, and that can't be overrated.

I was willing to be aggressive with my first interview, noting that I would be able to accept a lower-than-market rate if they would do a salary review shortly after I started. Not everyone is in the position to do so, but I took a 'whatever it takes' attitude to get started, with the confidence in myself that once people saw how effective I could be, things would get better. Programming is as close to a meritocratic profession as exists, so get in a position to prove yourself.

I like all of this advice. The key threads running through it at which I nodded my head in agreement were:

1) Free software/languages 2) Cut corners (disqus) 3) StackOverflow. This was a super life saver as I never had someone next to me while learning to just ask a quick question. The response time on it is often incredible.

Focus less on your 'platform choice' or whatever, as that can actually be quite fluid. Programming is programming, so spend more time writing code in the beginning I'd say.

I'd second this notion, but with the added caveat that without a 'mathy' way to solve the problem, you can't get much beyond the first 15 or so (if you're good at math, great, if you just want to put down some code to solve a simple problem... I got frustrated :) )

What about a way to loop back, so when you make that sweet iOS app, @brenda25056 can know about it?