Hacker Newsnew | comments | show | ask | jobs | submit | lucisferre's comments login



I use this pattern occasionally, though only when there is sufficient complexity to justify it. I see it as a tool similar to CQRS or hexagonal architecture. It is a way to manage complexity in a more maintainable manner that is easier to reason about and test.

I'll often use it when building out tasks and services, where a simple model (data) is passed into a service (context) and interaction/behaviour specific to that task is injected into the model. In Ruby I'll typically use refinements to do this.

The primary purpose of this approach is avoiding model bloat in my code by being able to decompose additional complexity over time in a flexible way.

If you're interested in getting into DCI more deeply you might want to check out Jim Gay's "Clean Ruby" book (http://clean-ruby.com/)


IMO: This may be one of the important papers to read (also the link within it) because it gives such a good perspective on things. "Some sees the the Model View Controller model as some observer patterns, while it really is to map the datamodel of the program onto the users mind model" It provides a great perspective.


While it doesn't seem certain any price change has happened. A drop in pricing has been way overdue, the cost of computing power and memory has been dropping but not Heroku pricing. I get that Heroku is meant to be a "premium" cloud product, but it often doesn't feel like one.

This also may not be much of a drop for people with minimal production requirements. Under the free hours system, 2x1X was $35 now it may be $50 unless the Hobby pricing is factored in for the first 1X and it's $25 + $7 = $32. For 2x2X the price drop will only be $6.50. Still it's good that the cost to scale has gone down.

The paid hobby tier is actually welcome change, the limitations of the free tier (often used for staging and demo environments) were (are?) annoying. The ability to run 1 dyno per Procfile entry (instead of per app) is a welcome change, as allows you to fully mimic production without dyno scaling more easily at a lower cost. People were likely using while allowing them to pay a reasonable price for these low-traffic systems.

I have been saying for a while 1X dyno is underpowered and unnecessarily memory limited considering it's price (particularly for Rails apps) even before 2X was announced. If I had my way the 1X would be dropped in favour of the 2X at the same price and the 1X only used for hobby and things like a worker role handling infrequent job queue processing. These price changes come pretty close to doing that, while adding a paid, but low-cost, hobby tier for applications with very limited needs.

Let's hope this is actually serious.


GAE lost a lot of users in their price hike a few years back, so on the mid/higher end it makes sense. But, hiking on the low end may "save some headaches" but it puts off potentially moneyed ventures "with the bathwater" in a "no public restrooms" way. (Such "signs" are mostly pointless and just make the "shop" look discriminatory.)


Why exactly do you think calculating compound return and fees are mutually exclusive? If you want compound return net of fees then you simply calculate that. As a rule most mutual funds do in fact report their performance net of fees.


You can actually die in Monkey Island 1. If you're patient enough.


I think his issue may be more that it's hard to be certain of this difference because it's relatively small and there are many other factors at play. He also doesn't say how many times he ran this test, but assuming he does sufficient test runs then I'd agree a 300-600ms difference is worth it.


@lucisferre, you're 100% correct here. I certainly don't ignore 300-600ms differences but I only look for them after I've exhausted other, perhaps larger, gains.

As for how many times the test was run, it was randomized but but somewhere between ~60-100 times.


Agile stuff like this just reeks of micro-management to me. To add insult to injury I recall one presenter at an Agile conference a few years ago explain how they added a "delta" value to their velocity so they could also report on the rate of change of their rate of change... Funnily enough they stopped short of just calling it "acceleration". Ugh though.

I have yet to see this type of process and measurement add value or productivity to a project. But perhaps that's just my experience.


Yeah. My old group at Microsoft started doing "agile" and it just turned into a micromanagement field day, with PMs and middle management in meetings examining charts and calling people on the carpet for missing their estimates.

Look, they're estimates . . . often made by other people than the ones doing the work.

(Oh, and having the build break for two or three weeks running didn't help the "estimates" very much. A culture of build breaking just rewards the people who are less careful than others).

I finally got the PM on our project to call our scrum meetings "status meetings" instead, because that's exactly what they were. Status for rollup into the Great Burndown Chart.

Over two years out of that garbage and I'm still bitter.

When you hear the words "Yup, we do Agile, but we have our own take on it," run away, because it's going to suck hard.


> When you hear the words "Yup, we do Agile, but we have our own take on it," run away, because it's going to suck hard.

Agile means doing it your own way. It means customizing what works for the team and the particular tasks.

Scrum is a fixed methodology with a rulebook.

(A lot of time "Agile" gets used to mean "Scrum" but the two aren't the same, or even the same kind of thing, though the Scrum Book is an often not-unreasonable starting point for an agile organization.)


> When you hear the words "Yup, we do Agile, but we have our own take on it," run away, because it's going to suck hard.

Every team/company has their own take on Agile, copying what other successful teams do verbatim doesn't necessarily work. There are objectively many wrong ways to do Agile (your above example being one) but not any single "correct" way.


No doubt. So, what does work?

Have you been on a team that has added productivity? Note that most teams get more done by adding labour, but that is not increasing productivity. Rather, getting more or better output per labour hour.

Then, how did you know where to focus effort to improve? And that you've increased productivity? Were the teams relying on improving tools, improving practice, and in what mix?


The basic problem is, there are good ways to run teams and bad ways to run teams, but the good ways in general are organic, contextual, intersubjective. It's hard to distill down to bullet points, much less a damn chart.

The most productive teams are the ones that focus on good people doing good honest work, being fairly rewarded, having a meaningful separation/delegation of responsibility/authority, communication, a knowledge of when to gather data and optimize against it and when not to, etc.

So, any time you try to distill team productivity on this cooperative creative endeavor into some number that you're going to put on a chart and give people shit about, you've already lost. If you don't already have a sense of how productive your team is and what the obstacles to increasing that are, chances are you're just a suit and you need to have someone else to run the team.


I run most of my projects under an organization so this doesn't really work. Also stars aren't really a great measure of anything after a point. Perfect example are the json-jwt and ruby-jwt gems. The latter gets more stars because it is arguably easier for people to find even though the former is a far more complete and robust implementation of the JWT spec.


Same here. I contribute a large part of my OS time at the moment to CakePHP projects - under an org - and Dokku - under another person's username. Everytime I see a site that ranks developers based on github profiles, I cringe a bit.

On that note, I'm apparently the 3rd top PHP developer in NYC. That strikes me as a bit odd, as Phil Sturgeon is also in the area. I guess they don't count "Bristol & Brooklyn" as NYC :)


We're trying to bridge the gap between private repos and public profiles. Nobody sees the work you put into your org-repos, but that work can still be shown on our leaderboard at https://wakatime.com/leaders


They aren't private repos, they are just open source projects I keep under my organization instead of my own account.


Oh got it. The good thing is WakaTime tracks the time you spent coding independently of the repo. We just use your repo when cross-referencing time spent per commit, but your public profile is populated even if you never use version control.

P.S. The current profile is basic but here's what it will look like soon: http://www.reddit.com/r/WakaTime/comments/2uqgww/mockup_new_...


My wife and I are co-founders and we have a 3 year-old daughter. Our startup is also still in its early stages, so things are pretty busy and often chaotic. I can definitely say that, as a necessity, we've become much better at time management than we ever were before.

Our days are fairly planned and we try to keep things routine as much as possible, consistency helps immensely. Also we've managed to ensure everything we need is fairly close by. We live about 10-15 minutes from work and our daycare and gym are both in close proximity to our office. We each typically have two scheduled mornings a week to hit the gym, one of us goes to the gym and the other deals with daycare. We also occasionally hand off daycare pick-up to allow the other to work a bit later. In fact, we hand-off on a lot of things to make everything work, particularly meetings, typically only one of us will go so the other can stay at work and grind on other things. As a software developer this is pretty important, I can skip out of a lot of meetings and keep working on product and we can catch up on what happened in the evening.

Having a child means our days need to be somewhat time-boxed so there's little room for severely late work hours. I actually believe this to be a good thing, as I'm forced to get the most out of my work time and continue to improve on my time management skills. That said, we're often catching up on things during downtime, weekends, evenings and since we live together, we have the advantage (or disadvantage depending on how you look at it) of being able to discuss work whenever we need to. To make things even more interesting my brother and father work in a related business, so family dinners can be... interesting.

Outside of that we try to keep everything pretty normal and we enjoy our downtime. We like to cook a lot, we make a regular trip to the market most Saturdays with our daughter. We cook dinner with our daughter often and eat at home often which provides valuable family time. The grandparents usually watch our daughter on Friday nights so we can hang out of with friends once a week as well, and we occasionally sneak out to have a drink together, after her bed-time, while they stay and watch her.

Almost all of our family lives nearby, so my parents and her parents help out a lot. It really starts to become a team effort to make everything work out without an excessive level of stress. I can't stress enough how important family is when things get to this level of "busy".

Like most people here, we love what we do. We don't mind being somewhat "always on" and we try to plan our lives in a way the reminds us to do other things too and not to neglect family and friends. That's the bigger challenge I think, not figuring out how to work hard at something you love, but remembering to live your life too.

Overall, we are very fortunate things have worked out as well as they have.


I'm also married to my cofounder and the experience is a lot like yours... Startup families are very tight:) Some people say "startup is a contact sport" but we prefer "startup is a team sport". Keep being grateful and good luck!


You mean like Netflix? There's already a comment here mentioning they've used both Ember and Angular internally.

Seriously, what a pointless comment.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact