There is no best position to work for long hours since the human body did not evolve to remain stationary for long hours day after day. Whether you work while standing or sitting, being immobile is worst thing you can do to your body.
Put it another way, your question represents a solution looking for a problem. The thing to do, which has been known for years in the "office space" is to take breaks. Put a timer that goes off every 20/30 minutes. Everytime the timer goes off, get up, rotate your torso and neck, try to touch your toes if you can, and take a walk around your cubicle.
Better yet, if you have a smartphone, get a Pomodoro app. Learn about the Pomodoro technique and use it. It's the best thing you can do to your body and brain if you have to work long hours with little body movement.
To me agile is just the latest buzzword. When I started my career then years ago it was "extreme programming". My first team claimed to be using it despite no pair programming or other practices I would associate with it.
To me "agile" is the way that many in house systems have been developed for years. It is only recently that the word agile has been applied to them (lets face it, almost everyone claims to be using agile these days).
My current work is to develop and maintain the in house database system used my a high throughput sequencing centre. We don't officially use agile, but looking at the agile manifesto http://agilemanifesto.org/principles.html, the way we work conforms to most of the principles laid out here. Regular frequent meetings, getting the software into the hands of users as soon as possible, frequent feedback, adapting to changing requirements. I haven't changed the manner in which I work over the years, but now I seem to be doing "agile" (more or less).
Bro, the agile movement (or buzzword) is almost as old as the XP movement (or buzzword.) "Extreme Programming Explained" was published in 1999 while the first Agile Manifesto draft was written in 2001, attempting to encompass similar methodologies of the vert late 80's and early-to-mid 90's. Back in 95, people were already (and rather empirically) were implementing lightweight methods moving away from rigid variations of iterative/spiral models (or waterfall if you were unlucky.)
Not sure how you can say Agile is the latest buzzword if you started your career at the dawn of XP.
Also, whether they are buzzwords or actual methodologies, that depend on the practitioner. I've seen people saying they are agile because they have no process or even source control. "Who cares about that, code and deploy directly on production. We are Agile!!!" At the other side of the spectrum, you have fundamentalist Agile-libans for whom they need to do every single religious step of Agile or XP regardless of the circumstances, like forcing people into pair programming irrespective of work culture.
In both cases, Agile (and XP) are just buzzwords, one for justifying shitty work, and the other to subordinate work objectives to mindless following of magical mantra.
Real software engineers do trade-offs, choices, pick stuff that work, and drop those that are not applicable. I've never seen effective Agilistas/XP practitioners that use every single thing in their manifestos just because.
Good software engineers will make things work be it with XP or Waterfall. Bad software engineers will fail regardless of methodologies.
Follow-up:
Math is nothing more than a language that allows the speaker to make very precise statements. If you can't see how this is useful in programming then no-one can help you.
I'm re-tweeting this in a post-quoting-whore fashion. If I could mod this more, I would.
The bulk of programming jobs have nothing at all to do with math beyond the high school level.
Its mostly counting beans and keeping records.
There is the activity of programming or coding, and the activity of software design. Coding by itself requires little behind HS math. Development/engineering, on the other hand, requires the person to have good analytic skills. From choosing the right algorithm or data structure to composing good architectures, they all boil down to understanding convergent and divergent series, discrete mathematics and combinatorics. To get to those fields one needs to have a good grasps of limits (ergo, Calc I). Similarly, every once in a while one has to make some form of probabilistic analysis at some point or another (ergo stats and Calc II).
Knowing mathematics at the calculus level or above does not guarantee a person to be a good software developer. But not having good analytical skills almost guarantee the person will end up writing flat class hierarchies, architectures without layering, writing n-cartesian SQL queries, and loops that execute very expensive invariants.
The error I've seen the most with developers with poor analytic skills is an inability to infer behavior from looking at code. That is, they are completely incapable of doing P->Q inferences. Worse still, they seem to have problems doing divide-and-conquer approaches. They cannot look at one piece of code, they have to look at the whole thing. When testing, they test the whole system in one single shot as opposed to testing and observing behavior of smaller pieces. In other words, they cannot handle complexity. They simply bang it - code it, compile it, run it, don't like the output, change it again, on and on until it prints the "right" thing (or things get hidden under the carpet.)
YMMV, but that has been what I've seen since I started my career in software.
Some people like to talk about computing without knowing its history. How did this made it to the/. front-page news?
"Back in the day, getting traction for a new programming language was next to impossible. First, one needed a textbook publishing deal.
Yeah, because COBOL and FORTRAN only took off after a mass of publishers got on it. Riiiiight.
Then, one needed a critical mass of CS profs across the country to convince their departments that your language was worth teaching at the university level.
Counter example: COBOL, FORTRAN, C, Java (the later two only took off after the industry was using them a plenty.)
And after that, one still needed a critical mass of students to agree it was worth spending their time and tuition to learn your language. Which probably meant that one needed a critical mass of corporations to agree they wanted their employees to use your language.
Where the hell do you get this stuff. Are you still in school or something?
It was a tall order that took years if one was lucky, and only some languages — FORTRAN, PL/I, C, Java, and Python come to mind — managed to succeed on all of these fronts.
FORTRAN took off because it was the best thing at the time for programming (much better than COBOL.) Java took off without the need of publishers or academia. It was simply taken by the industry. Python hasn't taken off (I love the language, but its usage is nowhere near Java or C#.)
But that was then, this is now.
You don't know what was "then". I doubt you know what it is "now".
Whip up some online materials, and you can kiss your textbook publishing worries goodbye.
What does this even mean?
Manage to convince just one of the new Super Profs at Udacity or Coursera to teach your programming language, and they can reach 160,000 students with just one free, not-for-credit course.
Yeah, because it will be as easy as it was before, right, right, right? Let's build a pyramid of hypotheticals!!!!
And even if the elite Profs turn up their nose at your creation, upstarts like Khan Academy or Code Academy can also deliver staggering numbers of students in a short time.
Yeah, because if up-start elite professors at Udacity or Coursera turn up their noses at your pet project, Khan will surely pick it up. Khan!!!!!!!!
In theory, widespread adoption of a new programming language could be achieved in weeks instead of years or decades, piquing employers' interest.
Because business rely in internet popularity and nothing when investing in effective technology.
So, could we be on the verge of a programming language renaissance?
I didn't know where were in a programming language dark age.
Or will the status quo somehow manage to triumph?"
Somehow this reminds me of Dora the Explorer when she stares at the audience waiting for an answer.
That is because corporate infrastructure software does not generate revenue.
Says who? That's like saying a cleaning crew or the electric system does not generate revenue for a supermarket. Revenue is not just a function of what you sell. You need a lot of things to generate revenue. A business that uses corporate infrastructure uses it to generate revenue. The problem in most unorganized enterprises is that they have poor accounting for tracking the cost and revenue of corporate infrastructure. Added to that is that most software developers have no clue about the cost and ROI of the software they build for a living (which is completely unnaceptable.)
Why spend money that does not directly impact the bottom line?
Maybe when you get people who actually understand the underlying business rather than a MBA graduate, that will change.
It's not just MBA's who don't get it. Software developers do not get it either. There is plenty of blame to throw to both sides of the fence.
C'mon man. Quality is contextual. Quality is determined by the cost it takes to operate the system. Cost is typically a function of the ease by which users utilize it to do whatever it is that they need to do (and the correctness and reliability of its output). That is, how does a piece of software facilitates an employe, for instance, in completing his/her tasks during the day.
Does the user needs to spend 5 minutes every time the system searches for a record? Or does the system completes the search in 30 seconds? Does the system provides good reporting capabilities, or does the user has to print multiple reports and then spend an hour creating his own from the provided ones (I've seen this case in real life)? Does the system prints the correct medical records for a patient, or does the nurse have to doublecheck every single report because the system can make mistakes from time to time.
Quality is always tied to cost. And cost is always an operational quantity. Someone has to use the system for it to be valuable. Someone uses the system to procure something of valuable. If the system imposes excessive cost (in term of unnecessary time spend using it), then the system is of low quality. If the system, on the other hand, facilitates users' productivity, then the system is of high quality.
A bugless program may still be a piece of shit.
There is no such a thing as a bugless program that is shitty. If a system is shitty, then it is a buggy one.
You can always come up with an edge case, like this one. But the edge case has to be valuable as a concrete representation of the problem. This example, without any specific details that describe why the system is shitty, of yours isn't one.
So what makes the system shitty? Bad ergonomics? Bad HCI? Too slow? Those are bugs, those are faults. A bug is not just printing the wrong outcome, or crashing. A system might compute the right answer for 2+2. But if it takes it an hour to print 4, then the system has a bug.
If a system is shitty, then that system has a bug or series of bugs that makes it shitty. There is no such a thing as a bugless system that is not shitty.
There are ways to determine quality.
One pretty standard way is to count the number of bugs found during testing each phase of development (design, coding, unit test, product test, integration tests and after its in production).
Those can be valuable metrics, but finding and fixing a lot of bugs can't improve the innate quality of the item under development/test. In other words, you can't test quality into the product.
Barring the most external layer at the user-facing interface, any quality of a software system at any level (architectural, design or implementation) is internal, ergo an "inner quality". But I assume you are referring to the architecture of a system. In that case, yes, it is true. However, architectural correction is not the only valuable type of correction. Also, for the typical enterprise system, architectural problems are not that important compared to the design and implementation decisions done day to day, and to the quality involved when writing the actual code (be it new development or bug fix.) It is only when you have very large systems (dozens of components and hundreds if not millions of line of code) and very large teams (20+) that make architecture truly crucial.
However, when you have a turd that cannot be re-architected (or when the re-architecting is not cost-effective), then the obvious (and only other sane) approach is to incrementally change implementation so as to gradually bring the beast (or at least parts of it) to a manageable state. A low-hanging fruit approach. I strongly suggest people to read Michael Feather's "Working Effectively with Legacy Code". Excellent read.
When we refer to the "inner quality" to all aspects of the system (and not just the architectural ones), bug fixing can effectively improve if active refactoring (boy scout rule) is part of the bug fixing process. Even without considering continuous refactoring, if a bug is fixed and the fix does not introduce another bug, then, however little it was before the fix, the inner quality of the system improves.
And if the system if of small or medium size, incremental code improvement typically facilitates the incremental improvement of architecture over time.
This is assuming that there are no additional morons dropping crap into the software (or a business/work environment that permits it and subordinates quality to get-that-code-out-yesterday). If that's the case, then now we are dealing with organizational issues that are beyond the realm of software engineering.
He's referring to businesses preferring low-salaried code monkeys over developers worth their money. The nuance is lost to most (a sad indictment not only on businesses, but on software developers in general.)
When it comes to software, yes. We have had it for decades: quality entails
architecture, design and implementation decisions that minimize the cost of change,
that does not deteriorate with each change (or at least deteriorates linearly with each change),
that exhibits strong cohesion and lose coupling,
that permits reasonable maintainability and configurability,
with relative small bug count per whatever metric one picks (FP, SLOCs, etc.)
that is amenable for testing
with architecture and design that are understandable (tied with #1)
Just to mention a few. There might not be a single universal definition of software quality, but there are common desirable attributes that have been known for decades. It's when people code without knowing these attributes (or not giving a shit about them) that we get the crappy stuff we get.
Software doesn't have to be perfect. It simply needs to be economical due to its qualities (again, qualities well known for decades.)
That depends on your definition of average, mathematically speaking that's not true. What percent of numbers are below average in this set: {1, 1, 1, 1, 1000}
This isn't pedantry, this is a meaningful distinction: I expect the amount of good software is extremely outnumbered by the bad, and even good software developers can be forced into kludges by time pressures, bad team culture, etc. I don't see any reason to think that code quality globally resembles a normal curve.
Indeed. I would actually think that global software quality resembles an exponential curve with x representing how craptacularly bad the software is. Very few systems are near the origin (and thus are well written.)
Funny how whenever regular employees get paid and treated well it's an "unsustainable bubble", but when executives get millions of dollars a year it's just business as usual.
Re-focusing on the main topic of my original post, how is (or was at the dot-com time) paying $60-$70K a year for a person to write HTML, just plain HTML not an "unsustainable bubble."?
That executives get paid millions is a non-sequitur to the topic at hand. Some deserve it (Larry Ellison, Steve Jobs RIP), some do not (Leo Apotheker). The topic at hand is the unsustainable dot-com bubble of the late 90's. I was there. I saw it. People getting overcompensated for jobs that weren't necessary or not complex enough, without having the skills that deserved such salaries.
This also went along universities changing their CS curriculum into poorly developed Java/NET training shops. As a result, we have people in the business for 10 years who still code as if they were sophomores. If the software industry were truly efficient at developing software (which we should because we have the knowledge to do so), I can guarantee you businesses wouldn't be so keen to offshore us out to reduce cost.
Yes, offshoring is a misguided option, and never brings the desired reductions in cost. But don't just blame businesses for doing so. The entire software industry does not have a moral leg to condemn them given the poor quality of software craftmanship/engineering in display.
Also, get this, when businesses really get smart about software development, they will stop offshoring. But also, when that happens, and when software engineering becomes more mature, they will stop hiring code monkeys that spew shit-code by the kilo-SLOCs/week. Then you will see more people out of IT/dev jobs.
You will also see good development shops having a core number of developers. OTH, shitty development shops (the standard as it has been all this time), you need an army of good developers controlling a larger army of shitty code monkeys, all of that necessary to make regular changes to the big ball of mud systems they are in charge of.
The truth is, if there is an ad, and if this ad stays for longer than 1 month, then it is fake ad, and there is no real need for this job position.
Not really. Positions for which there is a real need can stay open forever due to HR and management demanding Sr. level skills with Junior-level pay (or because they want to fill a Junior position but do not want Junior applicants.). I've seen this a lot.
Yes, the company goes on with IT/devs putting a lot more hours (and shit not getting done in time) because the positions are not getting filled. And since there is almost never good visibility when it comes to the cost and ROI of software and IT infrastructure, management can never really tell how much money they bleed out because of over-worked staff and delayed projects.
To say that a position that stays open for more than 1 month is a fake, that is extremelly simplistic and has little connection to how IT/dev shops run. Even in true engineering firms, positions can remain open for months for upcoming projects - it takes months to build and staff teams.
When I see job growth return to 1999 levels, then I will think things are getting better.
So you think things will be better if/when we see the fictitious job growth levels powered up by the dot-com speculative bubble, the time when it was possible for any greenhorn to get paid $60-70K a year just for writing html????? You are an interesting creature.
I for one prefer the status quo in IT/Software than the ridiculous dot-com bubble times. I would also say we are saturated - we have quite a few in IT/Software that are really not cut for this (testament of this is the shitload of crappy monkey code that exists despite all the advances we have made in the art and science of developing software.)
Do you have emotional problems, or are you just a bad person?
Maybe he has had to deal with code written by application developers who can't bother themselves to know how their apps affect (or depend on) their running environments. I would not blame him since that kind of experience is never pleasant.
Slaves hated Lobster for much the same reasons that people today prefer things like beef or "rabbit starvation" is named after rabbits.
Lobsters, like rabbits, have very low fat content. If your meat does not have fat, you are going to have to figure out how you're going to get fat into your diet.
Substituting starches for fats is not going to help you long-term. Your body will convert those starches into fat, yes - but the body will store it and not use it directly. You'll end up being hungry shortly after eating. You'll also end up suffering mental disorders due to fat nutrient deficiency over time.
But yeah. Lobster's great and all, but there's a damn good reason people dip it in butter sauce.
Eating a diet of bugs will suffer the same problem. They have zero fat.
That is absolutely not true. But let's skip that for a second, and address it as if it were true.
Those problems can be solved by efficiently and economicallyenriching the food with fats. Notice the words "efficiently and economically". This is a problem we can solve much better than our predecessors. There are quite a few sources of fat that are relatively cheap to mass produce - flax seeds, jojoba, algae, fruit seeds (from which oil is currently extracted for addition to pet food/animal fodder), palm kernels, grasses seeds, hemp seeds, plant roots. Many vegetable things that are not considered edible can be processed to extract edible oils.
Also, there is algae and krill that could be economically harvested and mixed with insect food.
But going back to your original claim, the claim that insects have zero fat is unsubstantiated. Grubs and pupae are known for their enormous fats and protein content, with the iconic Australian Wichetty grub leading the - moth larvae, rhino beetle worm, silk worm, termites, agave worm, ant and bee pupae and many others to name a few. Insect eggs could also be exploited that way.
I don't think you need to be any kind of zealot to think that multiple languages confuses a child. My wife's first language is not English. Many of her immigrant friends have children who are learning to speak English and another language. They are slower at first.
Slower with respect to what? With what objective measure????? My daughter speaks English and Japanese (from her Mother) and understand Spanish (my language) when I talk to her, and can count in all three languages. She is only 3 and a half years old. I don't see any confusion or delay in her progress (and neither 3rd party observers, including my sister who is a speech therapist and whom I asked her to evaluate her just in case.)
My nephew speaks English and Spanish from a very early age. He simply picked it up, and he's been on and off in learning Arabic (his father's language). My other nephew only spoke English, but once he was taken on a trip to our country of origin for a few weeks, he was speaking Spanish, reading it completely shortly thereafter.
I would say that immigrant children of low-income families are as slow as mono-lingual children of equally disposesed (sp?) families. And with immigrant families in general (and Hispanic in particular), the income/education gap is true. But language or the presence of multiple languages, that is a factor. At the most, you might be seeing correlation (which we all know does not imply causation.)
Sometimes they are confused about who speaks what language. Many times one of their children has come up to me and started babbling in a language I don't understand.
But that's not confusion from children. They are simply talking naturally. They are not confused on what they are saying, and they not know that you don't know their language is not a symptom of a learning or cognitive deficiency. My daughter babbles to me in Japanese a lot of times, and I need my wife to translate. But for the most part she speaks to me in English and in Japanese to her mother. At no point in time my daugther is confused or having a cognitive problem in expressing herself when she speaks Japanese to me. You are confusing issues here
Since small children are basically psychopaths (don't know right from wrong) they can't tell who understands or not.
No, they are not psychopaths. They have still underdeveloped cognitive skills. Two different things. Poor choice of terms for building an allegory.
Talking to you in a language that you do not understand is not a wrong, just as it is not a wrong for them to not know, for example, that something still exists even when it is no longer in their view (remember kids crying when they don't see mommy, because they think mommy doesn't exist anymore?)
Over the long term they catch up
Yep, in about a year or two at the most.
but if you were trying bilingual children without *needing* to
Who in his right mind nowadays can say that they children do not need to be bilingual, or at least have a minimum working knowledge of a 2nd language should they ever aspire to something?
or if both parents spoke only one language, it would be pretty easy to just say "it confuses the children" and give up.
Herein lies the gist of it, it is people who (in your own words), just say "it confuses the children", and give up. People who are more prone to give up on that will also give up on other topics they do not understand (math for example.). But it has nothing to do with a 2nd language confusing people (or parents). Some parents are just lazy, and others are simply rightfully overwhelmed (it is not easy being a parent, I KNOW.) But this argument has nothing to do with "children confusion."
My own son is only 4 months so he isn't saying much of anything, but based on the experience of our friends, he will be a little s
Monolingual zealots (typically of the borderline racist kind). Seriously, YMMV, but the only type of people I've ever seen making this claim are the type not typically happy with people speaking a foreign language around them. I don't understand what they are talking about, so they must be talking about me!!!". It feels like a long time ago, the early 90's when you could still see the bigotry the hatred. It was regular topic in the news, of employers firing their employees because they were talking Spanish or Vietnamese or Creole, or f* Klingon in the parking lot on the way home or during lunch (not on the clock, mind you, not on the clock.)
Now, the rhetoric has shifted from language to immigration status, and to a somewhat lesser degree to Islamic fundamentalism. The later two are based real issues - illegal immigration and Islamic terrorism. However, a significant number of people who bring these issues up do so to rationalize Anti-Hispanic or Islamophobic sentiments, regardless of their connections (or lack thereof) with illegal immigration or Islamic terrorism.
It is a generalization, I know, to say these claims are only made by people uncomfortable with foreign-language speakers. But it has been a generalization that holds true in my experience. YMMV obviously.
We just had a new vendor selection at my employer and IOS was chosen because the comfort level with security and malware on the Android platform is lower.
Actually, what I can almost guarantee happened is that some executive with no technical background whatsoever said "I love my iPhone, it's so shiny!", and the bit about security and malware was made up to justify that.
Who voted this informative?
Sadly, the/. crowd who think mindless dilbertian generalizations and overly abused cliches constitute statements of truth.
<necessary preemptive strike against slashdot fanbois>
And no. I'm not an iPhone fanboi. I'm actually an Android user.
</necessary preemptive strike against slashdot fanbois>
Geek, nerds, technocrats, whatever, they should be able to make statements like this immediately followed by a list comparing both platforms, followed by the most objective conclusion possible. Anything else is just hand-waving bull-crap more appropriate for technically-challenged marketing types than for the supposedly tech-oriented crowd that comes to these interweebz realms.
Except that preventing exceptions from crashing your program in C++ means preventing some exceptions from propagating -- and basically forces you to create programs that do not handle certain errors
I don't understand this - of course you have to prevent some exceptions from propagating - ie catching them. If you don't catch them anywhere, they end up in the default handler which usually stops your program by design.
I think he's referring to the poor exception semantics in C++, in particular that there is no exception "top" type. If that's not what he means, at least that is something I've had to face with when it comes to developing C++. As you know, a throw can take on anything, even an int. There is no exception type as a first class type, and as result, there is no "top" type for them.
But since anything can, in theory, be thrown at your code, your code must always have a catch(...) as the last catch of every try you have (if you want to print some time of line-code diagnostics, which is all you'll ever had)... or at the very least a catch(...) at the top-most section of your program/event loop.
Since you cannot determine anything at all from whatever that falls into a catch(...) block, you are restricted to do a "unknown error" handling operation, or to silently ignore it. Either way, that is a type of errors that you cannot effectively handle (note the wording, "effectively handle"). Logging a "something happened" error message (or ignoring an unknowable exception) to prevent a crash is essentially not handling the error to avoid the crash (because there is no way to effectively handle something that cannot be diagnosed.)
And that is the main semantic problem with C++ exception handling (on top of many others). C++ exception handling makes Java checked exceptions look incredibly appealing (and that is no compliment.) It is not only Qt that opts for error codes over C++ exceptions. A large number of very important systems (.ie. Azul's VM for example, or many C++ system in the defense sector) follow similar design decisions.
Exceptions are seen as magic error handlers by some people, but the truism that you should never throw an exception you're not prepared to catch is valid.
Another truism is to never assume the thrower of an exception is either you or some other entity under your direct control. In any sufficiently large/complex system, your code will be used by others, or will be layered over others' code base, or will interface with other component. In such situations, a exception mechanism without a "top" exception super type can quickly become more a liability than anything else. That uncertainty makes error codes a better alternative. Mind you that this is only true in C++ (but false in all other languages with true "top" exception types.)
Similarly, you could say you should never return an error code if you're not prepared to check it. The only difference is really in that checking code - the exception handler can be placed in a different location to the error handler code, which can often help code readability. That's all there is to it though, if you ignore an error code - fine you know the call may not have worked. If you ignore an exception - fine, you know your program may stop.
So how to make exceptions opt-out rather than opt-in... the only way is to inspect all the exceptions a piece of code will throw (and the code it uses itself) and then create handlers for each of them, or just wrap all function calls with a generic catch(...) handler which will at least provide a quick and easy way to catch all those exceptions, unless you handle them first. So the best practice is really to write the equivalent of a switch's 'default' case every time.
As a said, an exception system that permits generic catch(...) blocks but does not provide a "top" exception super type is a system that makes effective universal exception handling impossible.
Having a great toolkit that makes highly efficient applications and is source compatible on tons of operating systems? Where is the problem exactly? Oh, you must be one of those Java 'programmers'.
Because generalizations are the stuff smart people use to sound smarter or more technically proficient </roll-eyes>
And why the "hold the fuck on" anger anyway? Did this particular opinion on the rights of rape victims tickled you wrongly or something? You either side with a victim of a confirmed/caught on tape rape and her right to name those who raped her in the most aggravating of fashions, or you side by a gag order that denies that natural right in a most absolutist sense. This is one of the few things in this world that are truly black and white.
Hold the fuck on. You are going to have to prove that she was denied the ability to face her attackers (which is not an actual right, by the way. The right is of the accused to face their accuser).
And the accused wer found guilty, and the rape was verified (with a f* video of the rape posted by the attackers themselves), so the accused having to face the accuser part was already done, and after the guilty verdict, it is moot and inconsequential. So don't tell me that she has no right to confront her accusers (in this case, by naming them.) Also, not having a right under a legal interpretation (say a right to be free from slavery as it used to be some time ago) doesn't not imply that the right does not exist, has never existed or that it is not a necessary right.
The gag order simply doesn't allow her to mention their name.
A gag order mandated on the victim of a rape that was corroborated and even captured in video by the attackers, a gag order that, though legal, is unjustified and morally wrong no matter how you cut it. There is no way that it can be justified beyond hiding behind a flawed law and say "I'm just following the law."
Unless you can show that she was also denied the ability to be in the courtroom during proceedings,
I don't need to show it because the moral right of a rape victim to confront her attackers - a posteriori of a guilty verdict - is not limited to being in the same courtroom. It also extends to naming them should that action brings more justice to the victim.
Slashdot Mirror
What Is the Best Position To Work For Long Hours?
There is no best position to work for long hours since the human body did not evolve to remain stationary for long hours day after day. Whether you work while standing or sitting, being immobile is worst thing you can do to your body.
Put it another way, your question represents a solution looking for a problem. The thing to do, which has been known for years in the "office space" is to take breaks. Put a timer that goes off every 20/30 minutes. Everytime the timer goes off, get up, rotate your torso and neck, try to touch your toes if you can, and take a walk around your cubicle.
Better yet, if you have a smartphone, get a Pomodoro app. Learn about the Pomodoro technique and use it. It's the best thing you can do to your body and brain if you have to work long hours with little body movement.
To me agile is just the latest buzzword. When I started my career then years ago it was "extreme programming". My first team claimed to be using it despite no pair programming or other practices I would associate with it.
To me "agile" is the way that many in house systems have been developed for years. It is only recently that the word agile has been applied to them (lets face it, almost everyone claims to be using agile these days).
My current work is to develop and maintain the in house database system used my a high throughput sequencing centre. We don't officially use agile, but looking at the agile manifesto http://agilemanifesto.org/principles.html, the way we work conforms to most of the principles laid out here. Regular frequent meetings, getting the software into the hands of users as soon as possible, frequent feedback, adapting to changing requirements. I haven't changed the manner in which I work over the years, but now I seem to be doing "agile" (more or less).
Bro, the agile movement (or buzzword) is almost as old as the XP movement (or buzzword.) "Extreme Programming Explained" was published in 1999 while the first Agile Manifesto draft was written in 2001, attempting to encompass similar methodologies of the vert late 80's and early-to-mid 90's. Back in 95, people were already (and rather empirically) were implementing lightweight methods moving away from rigid variations of iterative/spiral models (or waterfall if you were unlucky.)
Not sure how you can say Agile is the latest buzzword if you started your career at the dawn of XP.
Also, whether they are buzzwords or actual methodologies, that depend on the practitioner. I've seen people saying they are agile because they have no process or even source control. "Who cares about that, code and deploy directly on production. We are Agile!!!" At the other side of the spectrum, you have fundamentalist Agile-libans for whom they need to do every single religious step of Agile or XP regardless of the circumstances, like forcing people into pair programming irrespective of work culture.
In both cases, Agile (and XP) are just buzzwords, one for justifying shitty work, and the other to subordinate work objectives to mindless following of magical mantra.
Real software engineers do trade-offs, choices, pick stuff that work, and drop those that are not applicable. I've never seen effective Agilistas/XP practitioners that use every single thing in their manifestos just because.
Good software engineers will make things work be it with XP or Waterfall. Bad software engineers will fail regardless of methodologies.
Follow-up: Math is nothing more than a language that allows the speaker to make very precise statements. If you can't see how this is useful in programming then no-one can help you.
I'm re-tweeting this in a post-quoting-whore fashion. If I could mod this more, I would.
The bulk of programming jobs have nothing at all to do with math beyond the high school level. Its mostly counting beans and keeping records.
There is the activity of programming or coding, and the activity of software design. Coding by itself requires little behind HS math. Development/engineering, on the other hand, requires the person to have good analytic skills. From choosing the right algorithm or data structure to composing good architectures, they all boil down to understanding convergent and divergent series, discrete mathematics and combinatorics. To get to those fields one needs to have a good grasps of limits (ergo, Calc I). Similarly, every once in a while one has to make some form of probabilistic analysis at some point or another (ergo stats and Calc II).
Knowing mathematics at the calculus level or above does not guarantee a person to be a good software developer. But not having good analytical skills almost guarantee the person will end up writing flat class hierarchies, architectures without layering, writing n-cartesian SQL queries, and loops that execute very expensive invariants.
The error I've seen the most with developers with poor analytic skills is an inability to infer behavior from looking at code. That is, they are completely incapable of doing P->Q inferences. Worse still, they seem to have problems doing divide-and-conquer approaches. They cannot look at one piece of code, they have to look at the whole thing. When testing, they test the whole system in one single shot as opposed to testing and observing behavior of smaller pieces. In other words, they cannot handle complexity. They simply bang it - code it, compile it, run it, don't like the output, change it again, on and on until it prints the "right" thing (or things get hidden under the carpet.)
YMMV, but that has been what I've seen since I started my career in software.
"Back in the day, getting traction for a new programming language was next to impossible. First, one needed a textbook publishing deal.
Yeah, because COBOL and FORTRAN only took off after a mass of publishers got on it. Riiiiight.
Then, one needed a critical mass of CS profs across the country to convince their departments that your language was worth teaching at the university level.
Counter example: COBOL, FORTRAN, C, Java (the later two only took off after the industry was using them a plenty.)
And after that, one still needed a critical mass of students to agree it was worth spending their time and tuition to learn your language. Which probably meant that one needed a critical mass of corporations to agree they wanted their employees to use your language.
Where the hell do you get this stuff. Are you still in school or something?
It was a tall order that took years if one was lucky, and only some languages — FORTRAN, PL/I, C, Java, and Python come to mind — managed to succeed on all of these fronts.
FORTRAN took off because it was the best thing at the time for programming (much better than COBOL.) Java took off without the need of publishers or academia. It was simply taken by the industry. Python hasn't taken off (I love the language, but its usage is nowhere near Java or C#.)
But that was then, this is now.
You don't know what was "then". I doubt you know what it is "now".
Whip up some online materials, and you can kiss your textbook publishing worries goodbye.
What does this even mean?
Manage to convince just one of the new Super Profs at Udacity or Coursera to teach your programming language, and they can reach 160,000 students with just one free, not-for-credit course.
Yeah, because it will be as easy as it was before, right, right, right? Let's build a pyramid of hypotheticals!!!!
And even if the elite Profs turn up their nose at your creation, upstarts like Khan Academy or Code Academy can also deliver staggering numbers of students in a short time.
Yeah, because if up-start elite professors at Udacity or Coursera turn up their noses at your pet project, Khan will surely pick it up. Khan!!!!!!!!
In theory, widespread adoption of a new programming language could be achieved in weeks instead of years or decades, piquing employers' interest.
Because business rely in internet popularity and nothing when investing in effective technology.
So, could we be on the verge of a programming language renaissance?
I didn't know where were in a programming language dark age.
Or will the status quo somehow manage to triumph?"
Somehow this reminds me of Dora the Explorer when she stares at the audience waiting for an answer.
That is because corporate infrastructure software does not generate revenue.
Says who? That's like saying a cleaning crew or the electric system does not generate revenue for a supermarket. Revenue is not just a function of what you sell. You need a lot of things to generate revenue. A business that uses corporate infrastructure uses it to generate revenue. The problem in most unorganized enterprises is that they have poor accounting for tracking the cost and revenue of corporate infrastructure. Added to that is that most software developers have no clue about the cost and ROI of the software they build for a living (which is completely unnaceptable.)
Why spend money that does not directly impact the bottom line?
Maybe when you get people who actually understand the underlying business rather than a MBA graduate, that will change.
It's not just MBA's who don't get it. Software developers do not get it either. There is plenty of blame to throw to both sides of the fence.
What is this number compared against?
C'mon man. Quality is contextual. Quality is determined by the cost it takes to operate the system. Cost is typically a function of the ease by which users utilize it to do whatever it is that they need to do (and the correctness and reliability of its output). That is, how does a piece of software facilitates an employe, for instance, in completing his/her tasks during the day.
Does the user needs to spend 5 minutes every time the system searches for a record? Or does the system completes the search in 30 seconds? Does the system provides good reporting capabilities, or does the user has to print multiple reports and then spend an hour creating his own from the provided ones (I've seen this case in real life)? Does the system prints the correct medical records for a patient, or does the nurse have to doublecheck every single report because the system can make mistakes from time to time.
Quality is always tied to cost. And cost is always an operational quantity. Someone has to use the system for it to be valuable. Someone uses the system to procure something of valuable. If the system imposes excessive cost (in term of unnecessary time spend using it), then the system is of low quality. If the system, on the other hand, facilitates users' productivity, then the system is of high quality.
A bugless program may still be a piece of shit.
There is no such a thing as a bugless program that is shitty. If a system is shitty, then it is a buggy one.
You can always come up with an edge case, like this one. But the edge case has to be valuable as a concrete representation of the problem. This example, without any specific details that describe why the system is shitty, of yours isn't one.
So what makes the system shitty? Bad ergonomics? Bad HCI? Too slow? Those are bugs, those are faults. A bug is not just printing the wrong outcome, or crashing. A system might compute the right answer for 2+2. But if it takes it an hour to print 4, then the system has a bug.
If a system is shitty, then that system has a bug or series of bugs that makes it shitty. There is no such a thing as a bugless system that is not shitty.
There are ways to determine quality. One pretty standard way is to count the number of bugs found during testing each phase of development (design, coding, unit test, product test, integration tests and after its in production).
Those can be valuable metrics, but finding and fixing a lot of bugs can't improve the innate quality of the item under development/test. In other words, you can't test quality into the product.
Barring the most external layer at the user-facing interface, any quality of a software system at any level (architectural, design or implementation) is internal, ergo an "inner quality". But I assume you are referring to the architecture of a system. In that case, yes, it is true. However, architectural correction is not the only valuable type of correction. Also, for the typical enterprise system, architectural problems are not that important compared to the design and implementation decisions done day to day, and to the quality involved when writing the actual code (be it new development or bug fix.) It is only when you have very large systems (dozens of components and hundreds if not millions of line of code) and very large teams (20+) that make architecture truly crucial.
However, when you have a turd that cannot be re-architected (or when the re-architecting is not cost-effective), then the obvious (and only other sane) approach is to incrementally change implementation so as to gradually bring the beast (or at least parts of it) to a manageable state. A low-hanging fruit approach. I strongly suggest people to read Michael Feather's "Working Effectively with Legacy Code". Excellent read.
When we refer to the "inner quality" to all aspects of the system (and not just the architectural ones), bug fixing can effectively improve if active refactoring (boy scout rule) is part of the bug fixing process. Even without considering continuous refactoring, if a bug is fixed and the fix does not introduce another bug, then, however little it was before the fix, the inner quality of the system improves.
And if the system if of small or medium size, incremental code improvement typically facilitates the incremental improvement of architecture over time.
This is assuming that there are no additional morons dropping crap into the software (or a business/work environment that permits it and subordinates quality to get-that-code-out-yesterday). If that's the case, then now we are dealing with organizational issues that are beyond the realm of software engineering.
You fools think it's going to be a dime or a dollar? The cost will never stop going up, and the quality of care will go down.
Boy you libs are so damn predictable.
You want 100% coverage, gee Cuba has had that for a long time now.
"Ohh I'll gladly pay [and pay and pay and pay and pay]."
Keep bending over suckers, the real hard part is just around the corner.
No, it hasn't. Ever been to Cuba, where you get an aspirin for free, for everything because that's all they have?
A better comparison is the health care systems of say, Japan, Canada or Israel... or almost any other developed country for that matter.
Yeah, serves them right for using Free Software.
He's referring to businesses preferring low-salaried code monkeys over developers worth their money. The nuance is lost to most (a sad indictment not only on businesses, but on software developers in general.)
Is there a real definition for quality?
When it comes to software, yes. We have had it for decades: quality entails
Just to mention a few. There might not be a single universal definition of software quality, but there are common desirable attributes that have been known for decades. It's when people code without knowing these attributes (or not giving a shit about them) that we get the crappy stuff we get.
Software doesn't have to be perfect. It simply needs to be economical due to its qualities (again, qualities well known for decades.)
That depends on your definition of average, mathematically speaking that's not true. What percent of numbers are below average in this set: {1, 1, 1, 1, 1000}
This isn't pedantry, this is a meaningful distinction: I expect the amount of good software is extremely outnumbered by the bad, and even good software developers can be forced into kludges by time pressures, bad team culture, etc. I don't see any reason to think that code quality globally resembles a normal curve.
Indeed. I would actually think that global software quality resembles an exponential curve with x representing how craptacularly bad the software is. Very few systems are near the origin (and thus are well written.)
Funny how whenever regular employees get paid and treated well it's an "unsustainable bubble", but when executives get millions of dollars a year it's just business as usual.
Re-focusing on the main topic of my original post, how is (or was at the dot-com time) paying $60-$70K a year for a person to write HTML, just plain HTML not an "unsustainable bubble."?
That executives get paid millions is a non-sequitur to the topic at hand. Some deserve it (Larry Ellison, Steve Jobs RIP), some do not (Leo Apotheker). The topic at hand is the unsustainable dot-com bubble of the late 90's. I was there. I saw it. People getting overcompensated for jobs that weren't necessary or not complex enough, without having the skills that deserved such salaries.
This also went along universities changing their CS curriculum into poorly developed Java/NET training shops. As a result, we have people in the business for 10 years who still code as if they were sophomores. If the software industry were truly efficient at developing software (which we should because we have the knowledge to do so), I can guarantee you businesses wouldn't be so keen to offshore us out to reduce cost.
Yes, offshoring is a misguided option, and never brings the desired reductions in cost. But don't just blame businesses for doing so. The entire software industry does not have a moral leg to condemn them given the poor quality of software craftmanship/engineering in display.
Also, get this, when businesses really get smart about software development, they will stop offshoring. But also, when that happens, and when software engineering becomes more mature, they will stop hiring code monkeys that spew shit-code by the kilo-SLOCs/week. Then you will see more people out of IT/dev jobs.
You will also see good development shops having a core number of developers. OTH, shitty development shops (the standard as it has been all this time), you need an army of good developers controlling a larger army of shitty code monkeys, all of that necessary to make regular changes to the big ball of mud systems they are in charge of.
The truth is, if there is an ad, and if this ad stays for longer than 1 month, then it is fake ad, and there is no real need for this job position.
Not really. Positions for which there is a real need can stay open forever due to HR and management demanding Sr. level skills with Junior-level pay (or because they want to fill a Junior position but do not want Junior applicants.). I've seen this a lot.
Yes, the company goes on with IT/devs putting a lot more hours (and shit not getting done in time) because the positions are not getting filled. And since there is almost never good visibility when it comes to the cost and ROI of software and IT infrastructure, management can never really tell how much money they bleed out because of over-worked staff and delayed projects.
To say that a position that stays open for more than 1 month is a fake, that is extremelly simplistic and has little connection to how IT/dev shops run. Even in true engineering firms, positions can remain open for months for upcoming projects - it takes months to build and staff teams.
When I see job growth return to 1999 levels, then I will think things are getting better.
So you think things will be better if/when we see the fictitious job growth levels powered up by the dot-com speculative bubble, the time when it was possible for any greenhorn to get paid $60-70K a year just for writing html????? You are an interesting creature.
I for one prefer the status quo in IT/Software than the ridiculous dot-com bubble times. I would also say we are saturated - we have quite a few in IT/Software that are really not cut for this (testament of this is the shitload of crappy monkey code that exists despite all the advances we have made in the art and science of developing software.)
Do you have emotional problems, or are you just a bad person?
Maybe he has had to deal with code written by application developers who can't bother themselves to know how their apps affect (or depend on) their running environments. I would not blame him since that kind of experience is never pleasant.
Slaves hated Lobster for much the same reasons that people today prefer things like beef or "rabbit starvation" is named after rabbits.
Lobsters, like rabbits, have very low fat content. If your meat does not have fat, you are going to have to figure out how you're going to get fat into your diet.
Substituting starches for fats is not going to help you long-term. Your body will convert those starches into fat, yes - but the body will store it and not use it directly. You'll end up being hungry shortly after eating. You'll also end up suffering mental disorders due to fat nutrient deficiency over time.
But yeah. Lobster's great and all, but there's a damn good reason people dip it in butter sauce.
Eating a diet of bugs will suffer the same problem. They have zero fat.
That is absolutely not true. But let's skip that for a second, and address it as if it were true.
Those problems can be solved by efficiently and economicallyenriching the food with fats. Notice the words "efficiently and economically". This is a problem we can solve much better than our predecessors. There are quite a few sources of fat that are relatively cheap to mass produce - flax seeds, jojoba, algae, fruit seeds (from which oil is currently extracted for addition to pet food/animal fodder), palm kernels, grasses seeds, hemp seeds, plant roots. Many vegetable things that are not considered edible can be processed to extract edible oils.
Also, there is algae and krill that could be economically harvested and mixed with insect food.
But going back to your original claim, the claim that insects have zero fat is unsubstantiated. Grubs and pupae are known for their enormous fats and protein content, with the iconic Australian Wichetty grub leading the - moth larvae, rhino beetle worm, silk worm, termites, agave worm, ant and bee pupae and many others to name a few. Insect eggs could also be exploited that way.
You sir, are wrong-o.
I don't think you need to be any kind of zealot to think that multiple languages confuses a child. My wife's first language is not English. Many of her immigrant friends have children who are learning to speak English and another language. They are slower at first.
Slower with respect to what? With what objective measure????? My daughter speaks English and Japanese (from her Mother) and understand Spanish (my language) when I talk to her, and can count in all three languages. She is only 3 and a half years old. I don't see any confusion or delay in her progress (and neither 3rd party observers, including my sister who is a speech therapist and whom I asked her to evaluate her just in case.)
My nephew speaks English and Spanish from a very early age. He simply picked it up, and he's been on and off in learning Arabic (his father's language). My other nephew only spoke English, but once he was taken on a trip to our country of origin for a few weeks, he was speaking Spanish, reading it completely shortly thereafter. I would say that immigrant children of low-income families are as slow as mono-lingual children of equally disposesed (sp?) families. And with immigrant families in general (and Hispanic in particular), the income/education gap is true. But language or the presence of multiple languages, that is a factor. At the most, you might be seeing correlation (which we all know does not imply causation.)
Sometimes they are confused about who speaks what language. Many times one of their children has come up to me and started babbling in a language I don't understand.
But that's not confusion from children. They are simply talking naturally. They are not confused on what they are saying, and they not know that you don't know their language is not a symptom of a learning or cognitive deficiency. My daughter babbles to me in Japanese a lot of times, and I need my wife to translate. But for the most part she speaks to me in English and in Japanese to her mother. At no point in time my daugther is confused or having a cognitive problem in expressing herself when she speaks Japanese to me. You are confusing issues here
Since small children are basically psychopaths (don't know right from wrong) they can't tell who understands or not.
No, they are not psychopaths. They have still underdeveloped cognitive skills. Two different things. Poor choice of terms for building an allegory.
Talking to you in a language that you do not understand is not a wrong, just as it is not a wrong for them to not know, for example, that something still exists even when it is no longer in their view (remember kids crying when they don't see mommy, because they think mommy doesn't exist anymore?)
Over the long term they catch up
Yep, in about a year or two at the most.
but if you were trying bilingual children without *needing* to
Who in his right mind nowadays can say that they children do not need to be bilingual, or at least have a minimum working knowledge of a 2nd language should they ever aspire to something?
or if both parents spoke only one language, it would be pretty easy to just say "it confuses the children" and give up.
Herein lies the gist of it, it is people who (in your own words), just say "it confuses the children", and give up. People who are more prone to give up on that will also give up on other topics they do not understand (math for example.). But it has nothing to do with a 2nd language confusing people (or parents). Some parents are just lazy, and others are simply rightfully overwhelmed (it is not easy being a parent, I KNOW.) But this argument has nothing to do with "children confusion."
My own son is only 4 months so he isn't saying much of anything, but based on the experience of our friends, he will be a little s
Who the hell thinks this?
Monolingual zealots (typically of the borderline racist kind). Seriously, YMMV, but the only type of people I've ever seen making this claim are the type not typically happy with people speaking a foreign language around them. I don't understand what they are talking about, so they must be talking about me!!!". It feels like a long time ago, the early 90's when you could still see the bigotry the hatred. It was regular topic in the news, of employers firing their employees because they were talking Spanish or Vietnamese or Creole, or f* Klingon in the parking lot on the way home or during lunch (not on the clock, mind you, not on the clock.)
Now, the rhetoric has shifted from language to immigration status, and to a somewhat lesser degree to Islamic fundamentalism. The later two are based real issues - illegal immigration and Islamic terrorism. However, a significant number of people who bring these issues up do so to rationalize Anti-Hispanic or Islamophobic sentiments, regardless of their connections (or lack thereof) with illegal immigration or Islamic terrorism.
It is a generalization, I know, to say these claims are only made by people uncomfortable with foreign-language speakers. But it has been a generalization that holds true in my experience. YMMV obviously.
We just had a new vendor selection at my employer and IOS was chosen because the comfort level with security and malware on the Android platform is lower.
Actually, what I can almost guarantee happened is that some executive with no technical background whatsoever said "I love my iPhone, it's so shiny!", and the bit about security and malware was made up to justify that.
Who voted this informative?
Sadly, the /. crowd who think mindless dilbertian generalizations and overly abused cliches constitute statements of truth.
and iOS was found MORE secure?
Good luck with that...
Elaborate. Elaborate precisely.
<necessary preemptive strike against slashdot fanbois>
And no. I'm not an iPhone fanboi. I'm actually an Android user.
</necessary preemptive strike against slashdot fanbois>
Geek, nerds, technocrats, whatever, they should be able to make statements like this immediately followed by a list comparing both platforms, followed by the most objective conclusion possible. Anything else is just hand-waving bull-crap more appropriate for technically-challenged marketing types than for the supposedly tech-oriented crowd that comes to these interweebz realms.
Except that preventing exceptions from crashing your program in C++ means preventing some exceptions from propagating -- and basically forces you to create programs that do not handle certain errors
I don't understand this - of course you have to prevent some exceptions from propagating - ie catching them. If you don't catch them anywhere, they end up in the default handler which usually stops your program by design.
I think he's referring to the poor exception semantics in C++, in particular that there is no exception "top" type. If that's not what he means, at least that is something I've had to face with when it comes to developing C++. As you know, a throw can take on anything, even an int. There is no exception type as a first class type, and as result, there is no "top" type for them.
But since anything can, in theory, be thrown at your code, your code must always have a catch(...) as the last catch of every try you have (if you want to print some time of line-code diagnostics, which is all you'll ever had)... or at the very least a catch(...) at the top-most section of your program/event loop.
Since you cannot determine anything at all from whatever that falls into a catch(...) block, you are restricted to do a "unknown error" handling operation, or to silently ignore it. Either way, that is a type of errors that you cannot effectively handle (note the wording, "effectively handle"). Logging a "something happened" error message (or ignoring an unknowable exception) to prevent a crash is essentially not handling the error to avoid the crash (because there is no way to effectively handle something that cannot be diagnosed.)
And that is the main semantic problem with C++ exception handling (on top of many others). C++ exception handling makes Java checked exceptions look incredibly appealing (and that is no compliment.) It is not only Qt that opts for error codes over C++ exceptions. A large number of very important systems (.ie. Azul's VM for example, or many C++ system in the defense sector) follow similar design decisions.
Exceptions are seen as magic error handlers by some people, but the truism that you should never throw an exception you're not prepared to catch is valid.
Another truism is to never assume the thrower of an exception is either you or some other entity under your direct control. In any sufficiently large/complex system, your code will be used by others, or will be layered over others' code base, or will interface with other component. In such situations, a exception mechanism without a "top" exception super type can quickly become more a liability than anything else. That uncertainty makes error codes a better alternative. Mind you that this is only true in C++ (but false in all other languages with true "top" exception types.) Similarly, you could say you should never return an error code if you're not prepared to check it. The only difference is really in that checking code - the exception handler can be placed in a different location to the error handler code, which can often help code readability. That's all there is to it though, if you ignore an error code - fine you know the call may not have worked. If you ignore an exception - fine, you know your program may stop.
So how to make exceptions opt-out rather than opt-in... the only way is to inspect all the exceptions a piece of code will throw (and the code it uses itself) and then create handlers for each of them, or just wrap all function calls with a generic catch(...) handler which will at least provide a quick and easy way to catch all those exceptions, unless you handle them first. So the best practice is really to write the equivalent of a switch's 'default' case every time.
As a said, an exception system that permits generic catch(...) blocks but does not provide a "top" exception super type is a system that makes effective universal exception handling impossible.
Having a great toolkit that makes highly efficient applications and is source compatible on tons of operating systems? Where is the problem exactly? Oh, you must be one of those Java 'programmers'.
Because generalizations are the stuff smart people use to sound smarter or more technically proficient </roll-eyes>
And why the "hold the fuck on" anger anyway? Did this particular opinion on the rights of rape victims tickled you wrongly or something? You either side with a victim of a confirmed/caught on tape rape and her right to name those who raped her in the most aggravating of fashions, or you side by a gag order that denies that natural right in a most absolutist sense. This is one of the few things in this world that are truly black and white.
Hold the fuck on. You are going to have to prove that she was denied the ability to face her attackers (which is not an actual right, by the way. The right is of the accused to face their accuser).
And the accused wer found guilty, and the rape was verified (with a f* video of the rape posted by the attackers themselves), so the accused having to face the accuser part was already done, and after the guilty verdict, it is moot and inconsequential. So don't tell me that she has no right to confront her accusers (in this case, by naming them.) Also, not having a right under a legal interpretation (say a right to be free from slavery as it used to be some time ago) doesn't not imply that the right does not exist, has never existed or that it is not a necessary right.
The gag order simply doesn't allow her to mention their name.
A gag order mandated on the victim of a rape that was corroborated and even captured in video by the attackers, a gag order that, though legal, is unjustified and morally wrong no matter how you cut it. There is no way that it can be justified beyond hiding behind a flawed law and say "I'm just following the law."
Unless you can show that she was also denied the ability to be in the courtroom during proceedings,
I don't need to show it because the moral right of a rape victim to confront her attackers - a posteriori of a guilty verdict - is not limited to being in the same courtroom. It also extends to naming them should that action brings more justice to the victim.
then you're full of shit.
Since you said so, it must obviously be so.