Why buy a computer from a company that has ties to the US government, an authoritarian government that supports dictators in Africa, the Middle-East, South America, and East Asia, including torture, drug smuggling, misogyny, and has itself engaged in abduction, detention without trial, and in relation to this case, illegal interception of communications?
2.) In the way that a company can be compelled to comply with an order from the government, including the requirement that the company may not disclose to anyone the nature of that order or the gag order, and that there is effectively no way to challenge such orders in a court of law.
>Have you actually lived in a country that has no elected representative?
> Favourable to or characterized by obedience to authority as opposed to personal liberty; strict, dictatorial.
It's certainly reasonable to argue about whether this actually applies; but I don't think that it represents a useless dilution of the word to think that it might. (Well, not 'dictatorial', but the rest of it.)
> It's certainly reasonable to argue about whether this actually applies
literally that it is reasonable to argue, i.e., that neither position is obviously irrefutably true; and also I think I've created enough of a de-rail already here; but, if I had to make an argument for authoritarianism, I think that I would claim that the concept of free-speech zones instantly implies, for some parts of US government at some times, more respect for authority than personal liberty.
You know, you can have "elected" "representatives" and still be authoritarian. You can make sure the ballot only has people you like on it, you can ignore what the representatives have to say, you can lie to the representatives so their decisions are compromised, you can restrict the flow of information to the electorate so their decisions are compromised... All of the above happen in the US. Hell, China has elected representatives - they're just all from the same party.
"Don't blame me - I voted for Kodos." - Homer J. Simpson.
Am about to buy/build PC right now. It will be a six-core socket 2011 CPU with a couple of 780s. All the CPUs are little 1150s. Guess I'm not your target audience?
(That was a response to a different benchmark, also done by Thumbtack, but it looks like it applies just as well to this one. See my comment at https://news.ycombinator.com/item?id=7944226.)
Here's another quote: "For every complex problem there is an answer that is clear, simple, and wrong."
My experience, anecdotal as it is, is that an open space per team is the most effective. This being science, when has the truth ever been precisely one end of the spectrum or the other? I'm naturally skeptical of pundits, advocating science, who point out that developers with their own office perform better than developer who share an open space with the call center and then claim that this demonstrates that private offices are the best solution.
The key quote from the article is "quieter and more private".
Maybe in the days when The Architect wrote a design doc and The Engineers went into their offices for six months, then a private office was a great way to get to the "Oh fuck this thing will never work" moment faster.
In contrast most teams I work with collaborate at the feature level: engineers work on the same feature, implementing different pieces together, before moving on to the next feature. We have other teams where individual developers take a feature and go off and work on it for a few days. The "individuals" are "faster" claiming work is complete, but the "teams" are faster at producing work that is accepted.
I should also add that while the team environment works for most engineers, we have some that absolutely require a private space, and we try to accommodate them. Individuals work differently and when we find someone good we try to make the environment work for them.
The simple answer is that these office plans are cheaper. It's a common business pitfall. The cheaper short term solution wins in spite of long term health productivity and culture advantages.
That might be true in some cases but there's an entire industry built around renting open-plan workspaces to solo founders and freelancers who freely choose to spend an extra $5000 per year and an hour's commute time each day because they feel an "office environment" surrounded by other busy professionals focuses their mind better than the serene quiet of their bedside desk. Many of them are developers.
Some workplaces don't limit it to "an open space per team", but mix multiple teams, whose distractions aren't relevant to other teams, in the same big room.
"In contrast most teams I work with collaborate at the feature level: engineers work on the same feature, implementing different pieces together, before moving on to the next feature"
Collaboration is much better with private offices. If Steve and Jim and Sally are working on a feature together then they can all take their laptops into Steves office and work on it together.
On the other hand even something as simple as pair programming in an open office can disturb dozens of other people. Where I work teams will book out meeting rooms for a few days at a time just to be able to collaborate without annoying the rest of the floor.
What is good architecture? I subscribe to the idea that we are doing software engineering and as such there are some "generally" understood principles such as SOLID, the Law of Demeter, Cyclomatic Complexity, etc that provide objective measures of "good" architecture (I apply SOLID all the way up the architecture hierarchy not just on classes).
What I've noticed is that TDD results in code that scores well against these measures, while code that scores well is easy to test (i.e. after writing the code).
Therefore, I think the argument that TDD creates bad architecture is false.
About 25 minutes into the talk we get to the crux of DHH's complaint and it is that Hexagon is an alternative to the Active Record (which he created) and the only reason Hexagon exists is to allow TDD. Hexagon requires throwing away the really useful code that is Active Record.
Hexagon appears to be an attempt to introduce sound software engineering practices (SOLID etc) into the Ruby world (with what success I do not know). Active Record and Rails in general is really useful if what you want is what it does, but sometimes its not. The implied claim that Hexagon is a bad architecture is false. The claim that Hexagon only exists to facilitate TDD is false.
"Mocks returning mocks returning mocks"
I use mocks. Fowler and Beck said on the whole they don't use them which genuinely surprised me. They cited examples of code where the test actually enforced implementation rather than purpose. I think that's probably how I wrote tests for the first few years. Code that results in mocks returning mocks returning mocks is code that is violating the Law of Demeter. Its bad code. It happens to be really hard to test, and it happens to be really hard to write tests first that way. Universally I've only ever seen tests like that when the tests were written after the code. TDD doesn't produce code like that because its easier to refactor it rather than keep digging that hole.
Mocks returning mocks returning mocks is a symptom of not doing TDD.
"My mind works differently... I have to write code first"
Spike. Problems that I don't know how to solve I spike first (I write code with no tests, or with tests only as drivers of execution). That's easy. The hard question is, "Now I have all this code, I have to throw it away and TDD it?" That's pretty hard to stick to in a business environment. I choose to write tests-after for all those pieces of code that already meet SOLID metrics, and rewrite the code (using TDD) for the pieces that don't. The pieces that don't are very difficult to write tests for after, and they also happen to be the pieces where I find bugs (for example, I'll cut and paste a bit of logic and find its wrong for one set of inputs).
"All code should have full coverage of automated tests"
All three agreed that this is the case. Fowler: "If you have a full suite of tests I don't care how you got it [TDD or not]". I don't know about you but I'm still fighting this battle. I also have to deal with teams that have a "full suite of tests" and 80% test coverage, but where every single one of those tests simply executes code. No actual "test" occurs. Indeed, in particularly memorable test, I managed to delete 70% of the lines of code and all the tests passed (including deleting the one line that was the main purpose of the method). Approximately 90% of all the tests were complete garbage: they reported success as long as the code didn't throw an exception.
> I subscribe to the idea that we are doing software engineering and as such there are some "generally" understood principles such as SOLID, the Law of Demeter, Cyclomatic Complexity, etc that provide objective measures of "good" architecture
Cyclomatic Complexity is not a principle, it's a specific measurement of potential complexity.
Law of Demeter is a guideline
SOLID is an object oriented-centric set of principles.
These are 3 completely different things.
You then go on to state using these makes software more testable. Since TDD can only exist in "testable" code, TDD is good design because these measurements/guidelines/principles are good design.
It's a non-sequitur of epic proportions.
I guaran-goddamned-tee you I can write a piece of software with less cyclomatic complexity than the Linux kernel, that is not nearly as well designed. Conflating those two things is what it means to be PHB.
CC is simply a measurement of a specific type of complexity, and like all measurements, it means jack shit without context. For example. the measurement of 8 inches. Is that number high, low, or normal? Or put another way, are we measuring a mans penis, a mans leg, or a mans hand?
this is why so much software turns to shit. This right here. The process by which you make decisions. If it's a good process, you'll have a tendency to make good decisions. If not, as illustrated by the post above, you will have a tendency to make bad decisions. A series of mostly good decisions will result in acceptable to good software. And the opposite results in unacceptable to bad software.
You want to learn how to write good, stable software? Learn to examine your thought process, and be explicit in your attempt to make good decisions. Be willing, and able, to identify bad decisions, why they're bad, and what you should have done instead.
What you did was believe the conclusion (TDD is good design) and then constructed the argument for it. DO NOT DO THIS. This is the stuff of bad decisions and software design failures, and this will happen regardless of which process you subscribe to.
I'm kind of shocked by how hostile your reply is! Not even 'passionate' - it's condescending, presumptuous, and isn't especially constructive!
The only part of this post that I think really deserves a good response is
You then go on to state using these makes software more testable. Since TDD can only exist in "testable" code, TDD is good design because these measurements/guidelines/principles are good design.
It's a non-sequitur of epic proportions.
That's not really what he said. He was saying that essentially there is a sort of design isomorphism - like a mathematical dual - between code test-ability and other desirable properties like compose-ability, low coupling, re-usability, and maintainability. The argument in favor of TDD says that building code out of a TDD process that requires testing means making design decisions that have this nice property of building highly compose-able code.
hostile? or blunt with a bit of dramatic flair. You'll take your pick based upon whether or not you agree with my position, that has nothing to do with me.
> That's not really what he said.
It is what he said, here's his wording, verbatim
_What I've noticed is that TDD results in code that scores well against these measures, while code that scores well is easy to test (i.e. after writing the code).
Therefore, I think the argument that TDD creates bad architecture is false._
You're interpreting things that were not said.
The entire argument is a non-sequitur. It doesn't even matter if you agree with him, an honest evaluation of what he stated would result in the conclusion that the conclusion absolutely does not follow from the argument.
The only thing that can consistently produce good design is good decision making. CC doesn't tell you anything without context, SOLID can be misapplied and is very OO-centric, and the Law of Demeter isn't even a principle, it's a guideline. It's like saying 'prefer composition over inheritance unless it's a clear win'. Ok great, but that doesn't actually result in a good design, it's cautionary guidance on what tends to be the better decision.
none of these things necessarily result in good design, and none of these things are required for good design. Hell, even the idea of 'good design' is nebulous and changes from 1 project to the next, and over time w/i the same project. Good design in a mobile app where energy is of the utmost importance is not the same as good design in a scientific application where correctness and verifiability are of the utmost importance.
The problem here is that you have yet another person coming to a conclusion and then working backwards in order to justify the conclusion. This is the sort of thing that consistently results in bad design __regardless of how many acronyms you follow_.
There is absolutely nothing in those ideas that intrinsically results in good design, or even intrinsically avoids bad design. That too was a part of DHH's point, one that a lot of people seemed to miss.
The conclusion does not follow because the conclusion came first. You mischaracterizing me as angry doesn't change that, but it is another indication of a flawed thought process (that the validity of the argument somehow stems from me being angry or not). Which brings us full circle back to the sort of thought process required for good decisions.
jamieb: here's a sequence of thought that explains why I think TDD creates good architecture.
mreiland: angry rant that seems only tangentially related to jamieb's comment
me: I'm going to say jamieb has a sensible opinion on the subject, though I don't entirely agree with him. And I'm going to assume mreiland has had a bad day, but he hasn't said anything that contributes anything to my understanding of the subject, jamieb's comment or discussion in general.
It's only sensible if you don't think too hard on it.
The point is similar to DHH's point, in that a process (in this case TDD) doesn't magically give you good design. Neither does following SOLID, understanding the Law of Demeter, or being aware of the Cyclomatic Complexity of your project.
jamieb thinks TDD results in great design (the conclusion). jamieb then decides to cast around finding a reason why. jamieb comes across a series of completely unrelated things that "makes things more testable", and since they're generally associated with positiveness, concludes that TDD isn't negative.
The conclusion does not follow the rationale. The point is that this is indicative of the sort of thought process that tends to create bad designs.
Rather than trying to push for more developers to be pro/anti-TDD, we need more developers who are simply aware of the decisions they make, and the process they use to come to those decisions. That will have a far larger effect than any amount of TDD ever will.
Cyclomatic Complexity as a measure of good architecture? Not from what I've seen. If you add internal consistency checks your CC score gets worse. (Add a check to make sure that your fast exponential always is going to return a positive number? You just supposedly made things worse.)
We have a guy on our team, let's call him Kent. He writes lots of tests, so many tests, mostly before he coded anything. Oopps. If he even prototyped a bit, he would have seen he was barking up the wrong tree. So he writes a whole battery of new tests. Now all his time is gone. He has to spend even more time. Let's call this the Martin syndrome.
We also have another colleague, he wants to have his cake and eat it. His name is David. He is now doing septagon testing. Does it benefit the project? Probably not, but it gets attention, and that's the important thing. For him.
Then finally, we have a colleague, who as always remains nameless and faceless. We never rwally notice these colleagues. They produce working code, with a few sensible tests as appropriate. They deliver for the client. They are not arching for book sales, conferences, blog spam clicks or anything else. They are the real professionals.
This problem is indicative of how screwed up our legal system is. Lawyers harass regular folks at-will as most people have no recourse (i.e. money to hire their own lawyer, or knowledge of the expanding and complicated laws).
Two ways I can think of fixing it - one is offering simple, straightforward hearings in front of a judge with the power to use their own judgement (instead of relying on overly-specific, exploitable laws); the other is to implement some counterbalance punitive fee for wrongly harassing citizens - something that decreases the profit ratio for predators and makes defending people in otherwise unprofitable cases profitable.
What do you think was happening in the months and months before the lien sale happened? There were a million opportunities to avoid the whole process through a straightforward administrative process, no lawyers involved.
That assumes you are still capable to follow that process. Apparently the current procedure does not take your present circumstances into account. (like mild dementia, alzeihmer, nursing home example in the article)
In Europe, once you get too incapacitated to take care of your stuff, social security take you in charge. After you die, they repossess your property and sell them to recover their cost. What's left is then given to whoever is supposed to inherit. I am not quite sure what would be acceptable with the more liberal US culture, but profiteering of the weak is certainly not an american value.
> Two ways I can think of fixing it - one is offering simple, straightforward hearings in front of a judge with the power to use their own judgement (instead of relying on overly-specific, exploitable laws)
Administrative hearings are used in a wide range of situations in the U.S. For example, when applying for federal benefits or under compensation programs. They're not a panacea. As organizations, they tend to become biased towards one side or the other. Good luck getting the Department of Labor to rule your way as an employer. One of the values of lawyers is that they force decision makers to justify their decisions to a sophisticated party, which reduces the tendency towards systematic bias or alternatively arbitrary action.
In the context of foreclosures generally, lawyers protect the lenders' interests. Foreclosure is already heavily stacked against the lender. The homeowner has months or sometimes years and numerous second chances to come up with the delinquent payments. Do we need to make the system even more biased by getting rid of the rules and letting a judge decide based on who has the most heartbreaking reason for not paying what they owe?
Incidentally, this situation also clearly demonstrates why the "loser pays legal expenses" rule is a bad one. When the loser pays, the biggest entity in the litigation has no incentive to reign in its legal expenses. Imagine applying "loser pays" to banks in foreclosure proceedings.
It points out this arose from a change in 2001 that occurred because the agency was trying to do LESS work, not more.
"But the work overwhelmed the agency, and in 2001, city leaders made a critical change: They told investors to head directly to court to file a foreclosure case.
The move empowered investors to start charging legal fees and court costs — a game changer that allowed them to turn minor delinquencies into insurmountable debts."
> a judge with the power to use their own judgement (instead of relying on overly-specific, exploitable laws);
Yes, because a single corrupt or idiotic or assholic judge should be able to ruin lives left and right without regard for the law.
> the other is to implement some counterbalance punitive fee for wrongly harassing citizens - something that decreases the profit ratio for predators and makes defending people in otherwise unprofitable cases profitable.
And you have another system to game, another way for the scummy lawyers to beat people over the head to prevent their crimes from being punished.
I'd rather take my chances with a judge than nearly guaranteeing failure in the current system. We already do this with small-claims court I believe and to be honest I'm not sure of the differences between that and a court that would handle a tax lien.
And yes, any system you make could be gamed, but you could make one that is harder to game than the current one.
It won't help much. Judge elections and appointments will then just be the focus of lobby groups. Watch the movie Hot Coffee to see how state supreme court judge elections are manipulated by business interests to install "friendly" judges.
Why not just make a law to cap the profits. Home must be sold at fair market price and the rest must be given to the owner.
> I'd rather take my chances with a judge than nearly guaranteeing failure in the current system.
Ah yes, the "Let that person solve it" school of fixing major social problems. It works really well right up until it fails really badly: George Washington was, for a while, effectively a dictator in that he could have been President-For-Life long before we came to associate that concept with bad outcomes; sadly, for every Washington who willingly resigns and refuses dictatorial powers, there are multiple leaders who exploit them to the fullest, possibly with good intentions to begin with, but that gets lost on the way to having a syphilitic strongman who eats the flesh of his enemies.
> We already do this with small-claims court I believe and to be honest I'm not sure of the differences between that and a court that would handle a tax lien.
Small-claims courts are, by their very nature, both high-volume and self-limiting: A judge-dominated process is necessary because we can't afford a jury to sit on every case involving piddling small change, and the fact they are limited to piddling small change means the amount of damage a judge can do is extremely limited. It's a trade-off, not a broad social principle.
A small-claims judge also can't just make shit up. The judge generally has to rely on precedent and law and uses his/her own judgement in areas where discretion does make sense.
You're argument that entrusting certain officials with making good publicly known decisions "works really well right up until it fails really badly" based off of a weird GW parable has me scratching my head.
And regarding small claims courts - the amount of damage a judge can do is directly related to how much a person is worth, just like fines for civil infractions. It can be nearly nothing or it can be life altering.
Anyway, the solution to this particular problem would be fine-limits (like in other states) and things like license-renewal restrictions (like you get for not paying a speeding ticket).
Edit: I suppose if people don't pay property taxes continually you have to sell the house to stop the tax revenue loss. Enforcing market-price restrictions might be difficult as lack of sale persists the problem. Maybe taking equity in the house at market price or something like that could work. Any way you look at it though $145 shouldn't be such a high-pri. Unpaid speeding tickets amount to more than that.
> You're argument that entrusting certain officials with making good publicly known decisions "works really well right up until it fails really badly" based off of a weird GW parable has me scratching my head.
You're the one who advocated that judges be allowed to ignore the law and judge entirely based on their own good judgement. I pointed out that there are few people who even have good enough judgement to abdicate at the right time.
> And regarding small claims courts - the amount of damage a judge can do is directly related to how much a person is worth, just like fines for civil infractions. It can be nearly nothing or it can be life altering.
That's why we have laws and we make judges follow those laws. It ill-serves society to force extremely good judges to follow poorly-thought-out laws, but the losses on that end are more than made up for by forcing the idiot and asshole judges to adhere to laws written by people who aren't explicitly out to screw you over.
I never said they should be able to ignore the law and judge entirely based on their own good judgement.
A single point of reference argument about people not having good enough judgement to abdicate (which relied on a case of abdication?) isn't a sealed argument that people/judges have bad judgement.
"but the losses on that end are more than made up for by forcing the idiot and asshole judges to adhere to laws written by people who aren't explicitly out to screw you over." Based on what? Why are judges explicitly out to screw you over? And are you joking that judges are more out to screw you over than law makers?
And your argument about idiot and asshole judges out to screw you over is coming from where? If I had to guess I'd say that most judges follow the status quo, a smallish portion can be pricks at times (but within the boundaries of the law), and the ones who truly go out of their way to be exceptional are doing so in the name of civil rights and civil liberties.
Your two-sentence summary is better than the entire article in understanding what's going on.
I read the whole article, and I somehow missed that sentence buried in the middle of the story. So Mr. Coleman wasn't "left with nothing" but presumably received something like $65,000 (i.e., $71,000 minus $6,000 or whatever the final legal bill was). Nowhere does the article say exactly what he received in the end.
The way the tax sale works sounds quite unjust and corrupt -- we don't need the reporter to make it even more evil ("left with nothing") by obscuring key facts.
No, that's not what happened at all. Try reading again.
>The Maryland company that took Coleman’s house sold it for $71,000 two months after evicting him. The company was owned by Steven Berman, who was convicted in 2008 in the Maryland bid-rigging case. He declined to comment. The law firm for Berman’s company said it was willing to reduce Coleman’s bill to $3,500 but could not reach him.
What part are you saying I still don't understand? The point I was trying to make is that Mr. Coleman does get some money from the sale, although unjustly much less than the house is worth. But the reporter is obscuring this simple fact.
> Not only did he lose his $197,000 house, but he also was stripped of the equity because tax lien purchasers are entitled to everything, trumping even mortgage companies.
That's not "obscuring this simple fact", that's stating clearly and unambiguously that your "fact" isn't true. The person you initially responded to was creating an example, based on how liens usually work. The reason the profit margins are so high in this case is that it doesn't work that way.
Ahhh... I use Noscript and the result is when I scroll down about 20 lines there's blank space, so I stopped reading and figured it was the end of a very short article...
So the $197,000 was likely the appraised value, with the $71,000 the actual sale value when the predators unloaded it.
But it sounds from the article like the original owner does lose everything, which I hope is so ridiculous as to be untrue, but I can't tell...
EDIT: I wonder if I got downvoted for using Noscript, or what...
Yep. All the good once are stuck playing *craft games.
Find a modern 8-year old, who understand PC circuitry (at analog and digital level), seen manufacturing processes, can re-solder components, can write C/assembly, can develop basic useful applications (like, say MS Paint). I bet you could easily find one like that, back in 70s-90s, particularly here in the silicon valley. Now - I'm not so sure.
Is'nt it the logical transition, at least in some schools it was, and i was thought the same way, begin with BASIC, and then as our curiosity increased we moved onto c and 8051 hardware/assembly.
