Threads for edward
-
Here’s a recent panel by organizers of the Software Patterns movement that offers their own perspective on how patterns were intended as heuristics to guide developers: https://www.hillside.net/home/news/327-patterns-principles-and-agile-connections?fontstyle=f-smaller
Recorded video is at https://www.hillside.net/videos/PatternsPrinciplesAndAgileConnections.mp4
It was particularly cool to hear Rebecca Wirfs-Brock and Ward Cunningham talk about how patterns came out of hanging out in the woods and applying Alexander’s ideas. Also interesting to hear how the wiki concept was borne out of wanting to share and collaborate on patterns.
-
Please stop adding author and summary to titles.
-
-
Generally speaking changing titles is not great–it confuses search, it adds opportunities for editorializing, etc.
If the title is vague, filling in the story description is usually a better option. That also lets you do things like link out to relevant background material.
-
If the title is vague, filling in the story description is usually a better option.
The real takeaway from the comment. For any new people reading, Lobsters' homepage has a symbol to the right of the title that looks like this…
http://graphemica.com/%E2%98%B6
…that links to a description giving extra info on the article. Result looks just like the page you’re seeing but with the text right under (example) “via ThisIs_MyName.” That comes from the text field of Submit Story. Most regulars seem to prefer you use it for extra details that might clutter up a title on front page.
-
-
-
Will do.
-
-
It’s fine to add them–just in the story description and not the title. :)
-
-
-
-
I agree with DHH’s statement that programmer happiness is all that matters. However, I haven’t met a Rails programmer that was happy writing Rails in, probably years. Everyone writing Rails constantly complains about how nothing works like expected, all apps become unmainable nightmares etc etc.
If programmer happiness matters to the Rails team, what’s being done to increase it?
-
I’ve said it before, but I wish the Rails team would invest more resources into maintaining an LTS branch. It’s easier to create happiness when a developer can just learn the tool once and get back to work without having to constantly learn the new version, spend time migrating code to it, fix broken tests, deal with incompatible plugins, etc. Unfortunately I think a lot of newer developers equate a stable project with a dead one, and they constantly want new shiny things.
I’m a happy Rails developer because most of the projects I work on are stuck on old versions like 2.3 and 4. I never have to think about upgrading Rails unless it’s for the occasional security update, so I can just focus on writing my application. If I thought about what it would take to pull all of these things up to whatever the current version is, it would make me unhappy.
Things like PHP succeeded because the language/interpreter moved very slowly (although this was bad for security, because certain things needed to change quicker) so developers could write code that still worked years down the road. This is kind of why I am apprehensive about learning Swift for iOS projects once it was open sourced - I think there are too many cooks in the kitchen trying to form the language around what they want, and it’s going to be a moving target for a long time.
-
IMO, it all depends on scale. Once the experiential barrier is overcome, Ruby provides short-term programmer happiness with its object-oriented/procedural orientation and eclectic grammar (deriving from Perl and Smalltalk), while Haskell provides long-term programmer happiness with its extremely versatile type system and pure functional-ness. Each has a clean syntax, but the underlying paradigms make for radically different programmer experiences. Ruby is great for churning out code that’s fun and natural to write without jumping through functional hoops, while for more sophisticated tasks it may perl in comparison with Haskell’s strong maintainability and reasonableness. That’s just one example, but you might see how what makes me happy may not make you happy, and vice versa.
Nevertheless, I wouldn’t call this a failure of Rails to make programmers happy per se; maintainability is a whole other problem that operates on an entirely different scale.
-
A big part of this is because frameworks try to cram all of programming into a tiny color-by-number box and call it good. Eventually what you’re doing doesn’t fit so well, but you’re already stuck there, so you just hack atop it.
Rails has enabled lots of projects to get bigger than they would have without it, but it doesn’t fix the fact that you need to know architecture eventually.
-
I’ve worked professionally for the past 5+ years on 7 or 8 projects that used Rails in various capacities. For me personally, Rails is awesome when you aren’t stuck using all of it. If you’re using the routing/controllers, sticking your business logic in a service layer and leaving everything else out, it’s a joy. While there is some small level of efficiency you gain from all the automagical stuff, my opinion these days is that the opacity hurts more than it helps.
Not to mention the… trendiness? Fad-culture? I’m not sure what the right way to label it is, but if you’re stuck trying to decide whether it’s fashionable this year to use helpers vs decorators (or was it presenters?), and wondering whether _changed? methods are deprecated this month, Rails can be quite a nuisance. Did “rake db:test:prepare” get undeprecated? Oh, lovely, I suppose we can use that again. Need to build an administrative backend for your own people? I guess it’s cool now to use ActiveAdmin, a deus ex machina gem that somehow attempts to what, simplify writing CRUD apps? I thought that’s what Rails was for.
</rant>
On a somewhat more serious note, I have worked on a very large Rails project where the performance of the application was perhaps the single biggest problem we had - largely ActiveRecord generating complex and inefficient queries which ended up being tediously re-written by hand. This wasn’t a Twitter-scale application, either. The Ruby language wasn’t at fault, but pieces of Rails certainly were.
-
While it may or may not be impossible to remedy the programmer happiness problem within Ruby/Rails, I think we’re missing something if we only look within that community. Jose Valim created a language and community that is making people really happy. Elixir was heavily influenced by Ruby, and (at the moment) it nails the programmer happiness point - so to say “Ruby/Rails makes people sad” is a little bleaker than reality, it certainly fostered some good ideas that made their way into other microcosms. I’m sure there are other examples, but the point is that all software ends up becoming unwieldy and unpleasant, but the nice aspects generally make their way into other projects.
-
-
-
Agreed! Better to just learn flexbox. Here’s a great gamified tutorial: http://flexboxfroggy.com/
-
I’m so happy _why is making a comeback :)
-
Is there an actual description with a list of features anywhere, not just an endless changelog of tiny fixes? I mean, I can’t even find out if it uses imap or maildir. Does it support any service other than gmail? (I hate that I even have to ask that question, but gmail only mail clients seem to be all the rage these days.)
-
Take a look at this screenshot: http://f.cl.ly/items/1b0y121A0o0x2V1M4512/Screen%20Shot%202013-03-26%20at%2012.24.28%20PM.png
- It looks like it uses imap by default
- It supports non-GMail clients
-
-
Hoping to learn Glamorous Toolkit / Smalltalk with a project around reporting potholes to my city. I want to extract EXIF data from pictures and upload details to a web form.