t4nkd

Is this just a really polite, introspective take on (Rails|Ruby) is a Ghetto? I can't point out one really valid critique in this entire rant. While I imagine that you've had enough kool-aid to actually believe the things you said, I think you should probably do a few google searches to find out how many shops are hiring Rails devs versus Clojure or Elixir. You can do more experimenting by seeing who else is actually working those jobs, what kind of professional experience they have, and if you're really lucky figure out what they get paid.

Rails needs websockets, just like years ago when it needed a better way to handle organizing and deploying assets. The modern application demands it, and if you've ever had the pleasure of trying to build a websocket application in Ruby you'd understand why it's actually really exciting that we're going to get the Rails community to build this for all of us.

If you want to be disenchanted about some aspect of Rails then pick the fact that the need for diversity at RailsConf this year has yielded some of the worst presentations I've ever seen (like, literally, the presenter spoke poor/broken english and the Docker oriented talks were about 6 months behind).

Rails moves the way it does and absorbs the ideas it does because they become popular. It's much easier to add a feature that everyone wants, instead of inventing a feature that makes a solved problem that much easier/faster/what-have-you. DHH seems to have to explain this every few years, but go back in time when Rails adopted sprockets and you'll see posts not unlike the one you just wrote.

Realistically, Ruby and Rails jobs are still among the highest paying in the industry. Startups and other more established companies still choose Rails as their platform, and not just for bullshit brochure sites. Certainly there remains a "best tool for the job" mentality but, right now, the alternatives are to: build it yourself, hop on a less "mature" framework -- Pheonix? I don't even know what you pick when you adopt Elixir as your platform language and need to build an API or front end apps but Pheonix won the google -- or choose from one of the popular technologies like Express.js, Laravel(?), or Django. That part of building technology (and business) didn't change, and there are still hundreds of thousands of Ruby and Rails engineers out there.

This^ is actually where my concern was.

Specifically:

> While in this case, we're getting less code in the dependency, I'm highly suspicious of how their working knowledge, method of code organization, etc... can be transferred over time.

I find it pretty interesting that the only real concern was "can this team solve my technical problem using the best tools in the shortest amount of time" but did not seem to consider things like, "What happens when this team moves on". One of the biggest assumptions that I've made is that when choosing tools, choosing the most popular ones gives you the highest chance of bringing someone on board who already groks them, finding learning material, etc.

I seem to be noticing more often now that "the best tool for the job, for the person, at the time" is completely acceptable. I feel as though this didn't used to be the case, and I know a lot of more "established" engineers who believe it's naive to choose tools based on an inclination or personal/team preference. While in this case, we're getting less code in the dependency, I'm highly suspicious of how their working knowledge, method of code organization, etc... can be transferred over time.

Ultimately though, knowing what actually happened over time with this project would be the most interesting. Does he eventually find new team members who convince him to switch back to a framework that is more widely understood and practiced?

This is the DHH everyone has come to expect, and enjoys reading. The entire premise of rails is based on putting negative light on configuration, this is sort of David's M.O.

The rails community has come to terms with the lack of pedantically focused programming practices that DHH embodies, however, his whole aura is one of an individual who has experienced extreme success, and therefore he's still an important community asset. He's a thought leader because he has created immense value from his opinions, and his vitriolic opinion of software architecture and abstraction has always existed. You can literally trace this back to RSpec.

I still argue OP isn't doing anything to support an opposite opinion, and is simply feeding the perspective that DHH was trying to be inflammatory instead of opinionated.

So, was this meant to be a counter point to DHH's article in any way? I really just got that you're mighty pissed that RR Parley banned some of your posts.

Dually, DHH didn't say TDD was dead, he specifically said "TDD is dead /to him/".

Really, I think the most important take away even for people who disagree, is this: > I don't think that's healthy. Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that's "slow". Like hitting the database. Or file IO. Or going through the browser to test the whole system. It's given birth to some truly horrendous monstrosities of architecture. A dense jungle of service objects, command patterns, and worse.

I'd like to see someone form a well constructed argument for why that statement is inaccurate, over-stated, or otherwise unfair instead of just ranting about how trying to disagree with what DHH posts ends up putting you on the receiving end of a bunch of zealous admins.

Wow, kudos to this perspective. I could have seen these design blogs rattling out a list of reasons why Yahoo's logo process isn't "The Right Way" -- namely because it reduces the process of designing a logo(and depending on who you ask, the entire brand) into a weekend with a small, internal team and the CEO. This kind of practice in a 10 billion dollar company is poisonous for professionals who chalk up big money on brand identity consulting and development. Imagine if Yahoo rewrote a major application in a weekend with a small team and the CEO; engineers would scramble to debunk that it could be accomplished, and work hard at discrediting the results of the Yahoo team who did it.

I think your perspective is probably the real take away from Marissa's blog post. Looking like small agile teams together in the trenches with big decision makers is the way bold ideas come out of Yahoo makes them sound leaps and bounds ahead so many other web giants. Thanks for your take, it was inspiring.

But Ben! What happens when spiders crawl your site and can't find comment content?

Youtube has had HTML5 opt-in for a while now, and it is certainly a technology used by their product: http://www.youtube.com/html5

Maybe I'd know the answer faster if I just tried, but, does this let people pair from, lets say, SublimeText to Vim? From the screenshots it seems to be one-way(sharing from a native editor to Floobits web editor).

I was way off!

Thanks.

So if nginx is "engine-x" does ngrok "negro-k"?

Or is it a "y" sound like "nguyen"...?

Yeah, I'm not really feeling the persuasion here. I really don't know many "frontend developers" or "backend developers" to begin with. I know plenty of people struggle writing maintainable, well structured applications or who don't grasp front end concepts/technology enough to really produce anything production worthy. Those people are still "my peers" first and I typically consider their title to be "software engineer" or possibly "web developer". The individuals lacking a grasp on front end technology probably need to learn just as well as an individual with great front end skills needs to learn the rest of the stack. We're so heavily coupled now, in terms of squeezing performance out of an application and the ability to iterate rapidly, that throwing a bunch of backend logic and/or API's over the wall to "UI Developers" is probably not only a waste of time, but detrimental to the process. Throwing code over a wall is usually what happens when two distinctly different types of engineers are in the same product and avoiding it is tricky.

All this opinion of course is coming from someone who has managed to develop design, UI/UX, and a programming skill set and I'm probably pretty biased when it comes to pidgin holing people into a single role. Having said that, this proposal really smells like an easy way to "be lazy" out of a responsibility in the project. Dismissing a UI issue by surrendering, "But I'm the Application Developer, I don't really do UI" sounds like the more common scenario in the roles you're proposing. The reality is, if you want to keep working on web-oriented applications, you might need to grasp a bit of both, or at least some of each and a lot more experience in either direction(e.g. learning the full stack and then taking a deep interest in hardware performance WRT application profiling).

Good luck with your ambition though, I'm sure if you can make it popular the industry won't care about how I feel .

Unless I missed a particular story, I haven't seen Summly or Yahoo! announce the number is $30m. A reasonable point here was that relicensing from SRI for the core functionality of this app could be a large part of the purchase price. Also, not being totally familiar with taking VC money, it sounds reasonable to me that a significant portion of the monies is going back to the investor(s?).

While I think $15m would have been fine and generous, it doesn't shock me that someone important in Yahoo! got it stuck into their head that Summly was hitting on something that would "change the way people use news", a particularly neat fit if their intention is still to be the new homepage of the internet.

So, what you're saying is, the next published paper will be on how Megauploads shutdown has increased the sales of music?

I wonder what dinner theatre ticket sales look like over this term, maybe digital piracy is killing the stage!?

So, using their extremely scientific method, did anyone else experience increased site traffic, or sales? I'm sure we can link other industries who deliver digital goods(software) so the closing of a digital locker site. Correlation === Causation; the pinnacle of statistical research!

Personally, I've seen a lot of qualitative analysis and anecdotal evidence to support remote working, specifically when it comes to technology companies. I've worked with a notable company who almost exclusively used remote employees and, from that experience, would never advocate remote work on a regular basis. It certainly has a place, for specific people of good standing and character who are put in an extraneous circumstance; but I've consistently observed what I believe Mayer has: smart people in the same space day after day will breed a more innovative, collaborative culture.

Most of the criticism that I've observed regarding the announcement seems to reek of the opinion that telecommuting is a "Good Thing" and that anyone who can't see that is missing the forest for the trees. This usually goes in hand with laughable academic braying and vaunted statistics about (some number less than 40) hour work weeks.

Forgoing my inclination to rant about how that kind of opinion is generally cancerous to an organization trying to change the landscape of it's industry through creativity, I think that Yahoo! is in a position where it can't afford to treat their employees like a productive group. And to that effect, it's much easier to identify shit employees who show up an hour+ late and leave with the herd at 5pm when you(or your managers) can observe that behavior regularly. Regardless of their output, I've observed that people who can't be bothered to adhere to simple routine will become an abrasive factor in a fast moving, creative culture; and tend to inevitably diminish the effectiveness of their peers. That kind of situation is the last thing that Yahoo! needs at the moment.

If Yahoo! can get out from under it's own sense of prior accomplishment and entitlement, and I remain confident that Mayer can do this for them, I'm sure she would consider a situation like remote working when it comes to top talent. But, until that happens, everyone there should be treated like a rich son in a boarding school -- assume the worst about most of those individuals and the one's who are weighing down the company will start to show their true color.

He's trading most of the simplicity for rich pre-rolled features.

Building your own authorization/authentication and integrating with OAuth is pretty trivial, maybe a few hours if all you need is simply logging people in. Same with a CRUD CMS that'd replace refinery -- you're collecting complexity for a more rich feature set out of the box.

Rack Rewrite isn't really that complex, though Carrierwave+Fog is a complexity layer, if Fog is anything like S3 you could just be posting directly to a REST api(adding complexity in client-side JS -- my favorite kind of complexity.)

Unicorn is slightly more complicated to manage than Passenger, but, apparently you needed to serve fast clients and work on disk a lot? Well, can't be mad about what it buys you.

Honeybadger, Foreman, and New Relic are pretty much DevOps burdens, you'd probably have some form or fashion of this complexity in any web-based app, ever. AMQP is a standard, most people would need a library to interact with it -- this is sort've akin to complaining that you need a library/gem for JSON.

I wasn't even sure you needed heroku as a project dependency -- I though you just needed it locally because it acted like a CLI to their service.

Also, Sinatra is it's own framework, having nothing to do with Rails. And it certainly wouldn't trade out a lot of the dependency complexity you're dealing with.

Really, you traded simplicity for rich features out of the box. Hopefully you took the time to figure out if you actually need those features before integrating them with your app. Also, Refinery's Engine architecture is kind've hair brained.

(P.S. on chrome 24.0.1312.57 and Mountain Lion the dynamic length comment box on this blog is totally fucked.)

This reeks of immaturity. Not since high school has the sentiment of "I'm wearing headphones to be left alone" been a popular or reasonable one. At least during those years, peers could look at you and make the mistake that you're so deep that music has more influence/meaning than the world around you. If this is, as I feel, an attempt to legitimize this kind of "signal" to other professionals who want to collaborate with you, I feel pretty sorry for the kid who's hosting this.

I can appreciate individuals who don't have the capacity to swap context throughout the day, but only when they can be mature enough to explain themselves to me like an adult; and I certainly don't need a visual accessory to que my interaction with them.

Aside from the photo gallery, which actually feels improved, I think everything else about this redesign went in totally the wrong direction. A massive sect of users is stuck in the "give me simple, stupid" mindset, and the platform popularity is really to blame. While it's a decent attempt at "beautifying" the interface, I think it's somehow more confusing.

Also, the design seems to be missing a way to shove hundreds of ad impressions into my eyeballs with each click -- a definite thumbs down in the facebook world.

For the record, my company would pay for this resource if I asked, and I don't see what's offered as being all together valuable to a professional who charges < $150/hr; only pieces of what's offered would act as a resource for learning, most of it would never be cannon reference material. I doubt any of those professionals you're targeting(< $150/hr) need wireframes or tutorial videos. More to that point, hourly rates like that don't go directly into pocket, as you may well know. It's not as simple as saying, "Find an hour of contract work and it pays for my bundle!", to try and justify the price in that manner makes me even more wary that there's not $200 of value in the product.

I'm just not convinced the asking price is justified. I'd be tempted to pay $80 for the book, all seven interviews, and the case study+bonus content. And, since I've touched on it, I'm kind've taken aback that 4 sections of the book were cut and added as an up sell; that just doesn't sit well with me. But even at $80, I'd expect a lot more quality in the interviews than I'd seen before; being unable to see some shorts, and basing my experience only on the freeview through the newsletter, I still wouldn't buy.

I hope, for the sake of the energy you've spent on this project, that I'm totally alien in the way I feel about your product. I hate to be disheartening or seem like I'm just playing devil's advocate to the positive reception you've had so far, that really isn't my intention.

Just to touch on your comment of "standard ebook prices" -- $30 is pretty standard. But when I pay that, I'm usually buying Manning or O'Reilly; getting early(beta) access and post-launch updates/errata. Also, I'm usually being written to by a community leader. I'm not trying to shoot down your integrity, but the people who write $30 ebooks tend to have significantly more provenance than yourself.

Wishing you success, thanks for the reply.

Agree, at first I thought Nathan had accomplished something for these companies. I thought it odd that he didn't make a bigger deal about his work for them. It was a shot to his credibility that I found he has never been involved in projects for these teams, or if he has, it's not discoverable.

The "complete package" gave me sticker shock, so much that I almost closed the page then and there. It was only out of curiosity as to why the $200 price tag was worthwhile that I even kept reading to find more purchase options. It put a bad taste in my mouth, honestly, and I'm left feeling pretty confused by why you won't let me cherry pick my own interview+book package. I'm just having trouble seeing the dollar value in what you've assembled, though I'm sure if I broke out each piece of what you're offering, it'd seem like quite a deal, no one is offering "pieces" of what you're offering, so I just see the whole thing as overpriced.

I was excited to follow the development of this through the newsletter, but I'm not a customer now. Maybe if you offered to trickle out the interview content as you developed it, for some kind of $9/mo fee? I would've been on board with that, or a similar approach. Though I guess not being a total squid I might not have been your target, I was really just interested in what those accomplished professionals had to say, maybe also thumbing through the book -- which while I'm at it -- I'm also not convinced provides the kind of value a $30 price should. I was kind've under the impression you'd include some real "how-to" meat, at least periodically, but there doesn't appear to be any of that. I think I'd get more value out of "Don't Make Me Think" or "Rocket Surgery Made Easy", and I could score both in a native kindle format(for $30).

I think you probably did a lot of hard work, and I'm still tempted to spend the $200 just for the interviews; but I don't feel good enough about what I might be getting. I saw the early version of the Ryan Singer interview and it didn't leave a $200 impression. I hope you've had a lot more success selling to others who really need a comprehensive resource or don't understand many of the fundamentals, it certainly seemed like it would be more valuable for them.

Also, just as an aside, the WordPress favicon feels cheap, and worse, lazy.

That's actually a much better sounding idea than just fragmenting the source into a whole new project, that will probably eventually suffer from disregard as Bootstrap continues to flourish.

In fact... https://github.com/twitter/bootstrap/wiki/Contributing-to-Bo...

Unless I'm mistaken the Air gives me slightly less horizontal space and slightly more vertical? And it's still a 13" form factor? How different could it be from the 13" MBP I run now aside from size/weight, hardware performance, and portability?

Fair response, the list wanted to be in question form, turned into hem hawing about anti-apple opinion. I'm still on the fence about 13" resolution and I can't seem to find resources to help me make the choice. Thanks for the reply.

Not very good, honestly. From what I've read, switching to a higher resolution wont really give me more work space, just make things more crisp, but I'm not sure how significant that would be for someone who wears corrective lenses already.

Maybe I'll look for some kind of 1:1 13" comparison...

As someone who's been using a Mac since 2008-ish, beginning with a 17" A4, I'm really considering buying this Dell and moving to Ubuntu permanently. I have a few gripes with Apple laptops and I was wondering if you could refute or lend an opinion on why(or why not) the Dell would be an option.

1) I really hate the hardware upsell. With this XPS machine I'm getting a 256gb SSD, 8G RAM, and an 3GHz i7 processor. The comparable hardware for a 13" Retina is $2,200 and it's still not as light or thin. The comparable Air is missing a GHz of processing speed and still costs an extra $150. Also, there isn't a team of OEM Apple developers writing Ubuntu PPA support for either machine, so I'm stuck on OS X again, which I'm pretty disillusioned with.

2) I'm actually still not really clear what the advantage of a retina display is. Maybe it's because I haven't been able to use one for a significant timespan, but I just don't get it. If there was a way to clearly and easily illustrate why a 13" display benefits from retina resolution, I'd really appreciate it.

3) I'm kind've ready for a change from Apple products. I haven't used a high end laptop or PC from any other manufacturer and I feel like I don't know what I'm missing, if I'm missing anything.

If you or the other XPS tester can respond at all, thanks in advance.

>> Could you elaborate on what sort of things would convince you?

What the money would actually be used for, which you just shed some more light on. It was really vague exactly which aspect(s) of the development the funds would be focused on, aside from "bringing the project to release", and you didn't really clarify how that's qualified. It's a highly technical project, I'd expect a little bit more meat.

Overall, I felt like there was some detail lacking with regard to the "how" of you getting to the goal. In theory, every funded development plan has some form of timeline(schedule/plan) and milestones, hopefully with some really vague dates or estimates. I just wasn't persuaded you had planned that far ahead yet. The project, based purely on the Indiegogo page, seemed to still be a hobby project that you enjoyed playing with. I simply can't justify adding to a $20,000 development fund based on the concept that you'll continue to flesh things out as you go along.

I haven't seen a serious track record of highly adopted open source projects from you(if I was looking in the wrong places or mistaken about the popularity of some of your projects, please correct me) and that doesn't persuade me to take you at your word. I'd need some meat in terms of what I'm actually funding and not what you hope to build. I can't in good conscience fund a project based on the end result or deliverable, I have to fund your process, planning ability, architectural consideration and senior experience; I could really only trust the last point, and not as much as I would have liked to.

I still appreciate what you're aiming to do, and that you've put so much energy into the concept already, but I don't appreciate it enough to contribute dollars. If you were looking for donations to continue to evolve the project after release and there was a community behind it saying good things, I'd be inclined to take the "end goal" as enough explanation and review the history of how things have evolved to see if I think you're reliable enough to fund. In this case, you want money to deliver an initial release, and I'm going to need to know how you want to get there.

Maybe I misunderstand the Perl Foundation grants model, but, isn't a great deal of that success due to the highly experienced developers who have already been contributing for years? Would the same success apply when the codebase in question has had little or no iteration?

Not to mention that TPF is a group of many committees who report to an entire board?

If there was mention of a governing board of developers who want to establish committees for developing the language further, I think that'd be a much more sensible and focused use of the funds. My perspective of his proposal was basically, "Pay a minimum rate for my time over the next 4-6 months and see where I can take this language". Something that leaves me even more uneasy is his ability to communicate the finer points of where this funding might be directed, or what the promise for delivery actually is. I have to believe there is some kind of metric for his progress thus far and his projections for progress moving forward; anything less is bush league panhandling for a hobby passion.

Just my two cents, obviously, and no offensive to the aims of the project author, which I actually think are interesting and probably worthwhile; but interesting and worthwhile are not cause for donation.

Am I the only one who's a little skeptical of this guys plan? Looking at this from an objective standpoint, and losing focus on the idea that Smalltalk is a great language that deserves this chance, the focus of this funding is being put on an individual who requires $20,000 for 4-6 months of work? Where do you factor in 2 months of wiggle time with a budget that low? Didn't he run the numbers? I have to imagine he took a look at his month to month expenses, subtracted luxuries, kept some "just in case I need a hospital visit" money? It seems like a 30 year dev would have a little money in the bank to keep himself working on /whatever/ passion he desires for at least 4-6 months?

I just think the whole financial aspect of this is fishy. And presuming that he raises enough money to get this project to the public, what if there's another 3 months of work before we can all really use it because of some oversight? Does the community need to kick him another $10,000?

His development architecture seems relatively sound from the 90,000ft. view, but there's not enough detail here to make me think he can actually pull off a 6 month development cycle of a new JVM based Smalltalk language. I don't really see any evidence apart from being a smart guy and passionate tinkerer that he could take a project to a community, maintain and grow it collaboratively, then end up with something thoughtful and elegant. While I wish this project all the best, he's done a very poor job of convincing me to give him money and I don't think that's just my obstinate view of failed crowd-funded development projects talking.