The science to it is basically this: When sitting, your metabolism slows, you burn less calories, and all the fun that goes with that - higher likelihood to be overweight, thus higher blood pressure, cardiac issues, and so on. We have studies that prove this too.
So, don't sit right? Well, standing isn't very good for you either, not for long periods of time. We're lacking any really hard science on what the optimal time period really is, although we know that it's variable depending on the person. We do know that you're more at risk for immediate health problems from long periods of standing rather than sitting (which results in longer term, less immediate issues). For example, even with a soft gel mat, after a few weeks, one stander ended up with medical conditions.. They're not just an anomaly either; back pain, carotid atherosclerosis - a circulation issue, varicose veins, pinched nerves, and more are associated with long periods of standing.
The fact is that we don't really know how much standing is enough to ward off the dangers of sitting, and worse, we don't know how much standing is too much and will result in health problems. There's probably an optimal healthy point, but we don't have any studies that show where that optimal healthy point is on average, much less how it needs to be adjusted for an individual.
It's also important to note that positive claims associated with standing desks that are not associated with physical well-being, such as increased mental capacity, creativity, memory, attentiveness, productivity and so on, are largely due to recirculating personal anecdotes, which we know carry a strong bias and use no objective measures for comparison. What few studies there have been show no evidence of benefit, nor of detriment. In a obvious note though, they show that treadmill or cyling desks DO reduce attention and productivity by a significant amount, and they haven't been shown to result in any impressive health gains either - users average weight loss of only about 3 lbs a year, for example, and that's about the only study you'll find on the subject!
What this all means is that, scientifically speaking, advocating for the health benefits of a standing desk is about the same as advocating for the health properties of barefoot running, clay cleansing (or really any cleanses, including charcoal, pickle juice, and others), and the whole genre of fad diets.
There's no scientific proof that shows they are a net benefit, which means you shouldn't assume they provide one. They are just standard junk science until then - taking a fact or finding and running with it past the point and on to speculation and pure fantasy. In fact, these are more akin to the fad diets, in that you're not only not gaining a benefit, you're that much more likely to cause harm to yourself. Standing desks are the new fen phen.
If you're worried about staying healthy, skip the fads and just add an exercise plan to your day. Take a 40 minute walk at lunch. Maybe workout a few times a week. Eat healthy, but more important in most western countries, eat a proper portion size. That's all it really takes.
There's a few problems here.
on
When Nerds Do BBQ
·
· Score: 3, Informative
Just to name a few:
1. The water pan is there to keep the brisket moist, which not only helps keep the meat from drying out, which also aids in smoke penetration (which is where the flavor comes from). It's not there to catch drippings. In the case of an egg smoker, it's also there to reduce the impact of different burns. 2. Offset smokers seem to be preferred by most "pitmasters"; direct heat really means you're grilling, not smoking, and that means you're mostly cooking over coals, rather than producing consistent smoke with an open-flame fire for the duration of the burn, and that means you're not getting enough flavor. 3. The "fuel" - given rather short shrift here - is one of the more important parts of bbq, and very hard to automate. Green wood, seasoned, large chunks or small, each has an impact on the immediate heat, the curve that the heat follows as it burns, and of course, the flavor via the smoke. 4. 220 lbs of brisket is decent, but good brisket places do 2000 lbs a day. If you're looking for something of quality instead of, well, acceptable, you're going to need to spend more time experimenting to figure out how to make a good brisket. 5. In order to have a chance to regulate the temperature well - and not keep cycling through blasts of heat and cooling - they'll need multiple temp probes, and an awareness of the outside temp and humidity as well, since ceramic insulation or no, the external environment will play a huge factor. 6. If the flat - the lean part of the brisket - is falling apart when you pick it up, the brisket has been overcooked. It means the point is going to have the consistency of pudding - or it's been destroyed entirely and is completely dry. It's harder to avoid this in a direct-heat smoker rather than an offset.
It should probably look like this. I remember seeing that shot in Franklin's book, Franklin Barbecue: A Meat Smoking Manifesto... which yes, sounds pretentious, but since he's lauded as the best BBQer in texas several times over, and that book is #1 in BBQ & Grilling books on Amazon, maybe he's allowed to be a bit pretentious. Go get that book if you're at all interested. Apparently fact checked by Harold McGee.
There's more things I could pick apart too. I know, I'm sounding like a BBQ snob, but the fact is that I'm not very good at cooking it, and I haven't had a lot of experience. However, like any geek, I did my research. I read around. I checked things up on the internet. I talked to cooks. I volunteered at some cookoffs. I think I have just barely enough experience to recognize when someone else is doing it poorly. Anyone who's done this at all isn't going to be very worried about this invention, since, well, the parts that you can automate are the parts that are least likely to affect whether your brisket is going to taste good. You may as well have just stuck it in an oven with a few blocks of aromatic wood in a water pan underneath at 275 for an hour and a half per lb.
C'mon folks. This is basic stuff when working with any hazardous machinery. This is entirely a human error, and the 'robot' aspect of it is unimportant. The word 'machinery' would have been less provoking. It's about the same as saying "Factory worker dies after jumping into industrial tire shredder with insecure controller hardware". The controller has nothing to do with it.
Granted, Europe doesn't have the same OSHA requirements as the US, but still, it's pretty obvious.
If you're not familiar with this concept, here's a summary & scenario.
Summary: You use a device to physically stop the operation of the machine that requires a lock, and then you keep the key to that lock with you so only you can re-enable the machine.
Situation: You need to rewire half a building. You shut down the power and lock the panel so no one can turn it on. You start work and now your hands are full of wire. At the same time, a co-worker's air compressor loses power because it's plugged into that downed grid, he comes over and wants to turn it back on, but since you have the only key, he can't. As a result, you stay alive. Alternatively, you don't lock the panel, and your co-worker electrocutes you.
If you're doing front end web development, at some point, you're going to have to become good at Javascript.
You've got all these different frameworks where everything gets abstracted 3 redirections deep into a pseudo MVC layer populated with promise events and callback system that work well for 80% of the job and make 20% incredibly hard, and STILL in the end ties into the DOM, and is just as breakage prone, all the while explicitly demanding you adhere to their code organization because that way they can encode configuration into class names and function invokations and all of them claiming the other is bad not because of intrinsic issues but because they don't make the same ideological architectural choices like one-page-apps or putting business logic (including navigation!) in pages - even though it's more predicated on popularity than functionality, and ALL of that built on top of the mess that is Javascript and you are well and truly sunk my friend. Not even a run-on-sentence has enough space to cover all the horrible stuff that lies out there for the aspiring web developer.
So I recommend learning Javascript. Once you have a good strong feel for the fundamentals, once you've treated Crockford's "JavaScript: The Good Parts," the same way as you've done with K&R's "The C Programming Language," and you're solid on the basics, THEN jump off into these new worlds of overly pretentious web designers delving into their first languages and claiming you can't write a decent site without coffeescript, haml, and sass. So you can put them in their place, or at least, so you can understand how much they're complicating what is, after all, not that difficult of a thing. Even experienced developers write really, seriously completely awful code with Javascript, thinking they'd doing a decent job because they didn't invest time and energy to understand why they're not.
The only problem is that Javascript is bad. I like learning by examples, but that is so not the way to go with Javascript. Examples abound - but they're more than likely to be bad examples. There's reference books, like "Javascript: The Definitive Guide," but they're not great for learning. So what I do is tell people to learn jQuery first.
With jQuery and a few minutes, they can pick up the basics. Someone who already knows CSS or writes code for a living should feel productive in less than a full work day. It's easy, it's fast*, it handles browser differences**, there are well documented examples of how to use each feature on the jQuery doc pages, and best of all for me - it's non intrusive, so you can fit in the new vanilla javascript you're slowly picking up in, without needing to learn any framework specific configurations or magic function naming or guessing why it's not calling a method because it's not been added to the object prototype by your pesudo controller registration.
For me, I hate frameworks that are all-or-one solutions. Big heavyweight*** frameworks that tell you "This webpage is now a ____ application". First, they never are perfect solutions, and second, they always make some percent easier at the cost of making the rest painful. I think when learning a new language, especially if you've already got one or more under your belt, forcing someone to do it your way, or making familiar patterns or constructs hard is a huge detriment. Besides, how can you expect someone to learn if they're not allowed to get it wrong? You end up with folks who don't understand the importance of things like memory management if they never had to do it, and how useful are they during crunch mode?
So, yeah. Learn jQuery. Learn dom traversal and manipulation. Learn event registration. Learn AJAX. Try out some animations. Write a plugin or two. Many of these things are appearing in modern browsers now, but once you understand the concept, the basics that are endemic to web development, and you can be productive, then you'll have the grace time needed to properly learn actual Javascript. Then you get out your
I'm not sure where to start. I'd like to do a point-by-point, but there's no need. The issue on my part is very simple:
People should be judged based on their own merits, not the color of their skin or their gender, not based on the socioeconomic class they're from, not by handicap or caste or because someone has a quota or a chart that shows an irregular curve they'd like to smooth out.
What you're calling 'social fairness' is actually quite unfair to society or individuals.
The issue with affirmative action-type policies is that it is saying, in no uncertain terms, capability is not as important as quotas. That folks who have been deemed capable should not only not be given opportunity, but that opportunity should be given to someone who has not been deemed capable. That can't be considered fair in any society - and before you complain, consider that this is exactly the policies apartheid & theocratic governments and pre-civil war US used. People judged based on their skin color, religion or other minority status, rather than their ability.
This is not just a matter of treating people as individuals instead of a member of a group as an ethically and morally correct stance. Treating people who are not capable of a job as qualified and allowing them to occupy important positions is a danger to all of society. How that can be lost on you, I don't know. This is the very root of the problem with nepotism and cronyism!
Perhaps this straw man scenario might help: "Your doctor isn't technically qualified to perform your gall bladder surgery, but we needed someone from a low income family on staff to round out the numbers. So... yeah... good luck in there!"
I don't think we're there yet with doctors, but it is already happening with police, firefighters, and other emergency personnel. How can you justify this by saying that it's acceptable or worse, preferable simply because some arbitrary binning of the population doesn't turn out equal numbers. I can't wait till someone notices there's not enough people with low intelligence being recognized as geniuses and tries to fix that.... yes I know it's absurd, but the whole concept seems crazy to me.
The short version is; certain states have ruled that colleges are not allowed to consider race as part of their admissions criteria, and medical schools are noticing that black and latino graduation numbers have decreased since then.
The intent was to focus on merit-based evaluations. Seems noble, right? We want the best doctors we can get. However, the effect appears to be to reduce the number of minority students admitted. This, of course, has people outraged, and scrambling to find ways to work around the system - like sending recruiting teams to primarily-black or latino high schools, and hoping that will increase the applicant numbers.
What shocked me is that everyone is dancing around the race issue (and only certain races; not, for example, Indian or other asians). Everyone agrees the minority graduation numbers have dropped because individuals from a given group don't actually meet the admissions criteria. They're not qualified to be students or doctors. That apparently hundreds or thousands of people's failing grades were ignored because of their race. That prior to the no-race rule, doctors, in this case, were not necessarily the most well qualified individuals for the job. In fact, some significant percentage of them should not have been allowed in.
This trend isn't new either. When I was a lifeguard back in the 90's, the requirements changed from being able to swim a specific distance in a certain time, to removing many of these fitness requirements altogether. The reason? It was apparently unfairly eliminating people with poor physical ability or handicaps. The new focus was to do all the lifeguarding from the side of the pool: hooks, ropes, and life preservers.
Heck, just last month there was a minor kerfuffle about fire departments force- and expedited-promotions of minorities over whites.
I can't help but see this girls-only computer science focus being another of these sorts of ill-considered plans, where capability takes a back seat to minority inclusion and political correctness. Sure, it's not as vital as our doctors, firemen, and lifeguards, but it's the same line of thought. In our rush to be politically correct and all inclusive, we mistake equality for equally fair, and it serves no one well except those promoting our differences.
Am I the only one who thinks this is crazy? Like Harrison Bergeron crazy? I can't be the only one, right?
Studies seem to indicate that this is largely due to the constantly shifting cultural landscape which says, for example, women make better psychologists and biologists now, whereas 30-40 years ago, that was not the case. It's not that men in general are hardwired to avoid nursing and want to be garbage men, and women are selected to be secretaries and beauty stylists, but rather, the culture they're brought up in acts as a filter to determine what jobs should be held by which gender based on cultural norms, based on no objective differences in ability or merit at all.
So it is the case that our culture is steering gender-based career selection, in an irrational, non-directed way. The bigger issue is: does it really matter all that much? Is it actively or passively hurting anyone? Would forcing equality, especially when it requires working counter to cultural values, really be any better?
My personal belief is that it won't, but there are a lot of loud, angry people out there who seem to think otherwise.
I'm assuming the article is referencing this data: http://www.randalolson.com/wp-.... That is a pretty striking curve, though there are two interesting points to make:
- Women have made consistent gains year to year in nearly every engineering and "hard science" field, some more than others (biology is a standout)
- The absolute number of women CS graduates is actually increasing as well - it's just that male graduate numbers are increasing at about twice the rate.
However, contrary to your claim, there are many, many people trying to asking why. There's lloads of speculation, but the ones that seem most reasonable to me point to a large scale cultural shift that considers women better youth educators (pre highschool teachers), psychologists, journalists, biologists, pharmacists, and a large drive into the agricultural job market. Studies have shown - as referenced elsewhere - that these cultural values are imposed early, and one of the major sources is the female child's mother, though popular media also drives some of this. This goes the other way too, with the cultural acceptance of male interest in video games potentially acting as a familiarization gateway to CS careers.
But really, we're only investigating ~that~ question because we're trying to solve a bigger one: How do we get more women with CS degrees and/or working as software engineers? If the studies are right, it seems the best way is to train new parents to stop limiting their children.
More important in my mind though: is that a valuable goal?
There is some greater potential for creativity in problem solving - meaning things like faster software, better interfaces, when you include a diverse body of people, but it's hard to measure that potential, or determine if it's been realized. There's nothing to indicate that given two individuals, one can be expected to perform any better than the other based on gender in this field, so it seems that if you myopically focus on one with a disregard as to their actual merits, you run the risk of hiring the worse performer.
Generally, I'd say that this is more of a non-issue. As we raise an increasingly tech-savvy generation, and negative cultural stigma of IT workers fall to the side, I think we'll naturally see more women in the field, as the work is fairly light and the pay is reasonable. At the same time, I don't think deliberately pushing towards that goal really serves the public or companies or women in any real way, and it may even be hurting it, as per the article's original question about gender stereotypes.
This is not anything we're not already doing, the difference is that right now it's incredibly difficult to do well, and the result is an intractable mess. Markup - and CSS is just an externalized form of markup - lacks any real power. It's simplistic, which makes it approachable, but not very flexible or adaptive. In order to achieve even simple goals, we're using fairly complex and increasingly obscured and inflexible markup. When that fails, we turn to javascript to provide liquid layouts that work, and cart this baggage of per-page non resusable javascript around with us, all of it ready to break as soon as we make any changes - or use a viewport we didn't consider.
What I'm suggesting is that we provide the same controls we have for generating a user interface for local software in web browsers. That means being able to programatically adjust layouts, styles, etc, without having to wrap javascript around them to provide for a responsive interface or implement common layout requirements. It means doing all the things we already do, but in a way that increases readability, maintainability and future modifications.
Basically, it means internalizing something like flash, without the proprietary nature and other detriments.
That's pretty much what this WebAssembly bytecode would do, and what I've been advocating for.
What you're talking about seems to have... absolutely no basis on either the article or my comment. I'm not even sure what it is you're suggesting. Letting other people run any program on your computer through your web browser? That does sound stupid.
It's nice that HTML and CSS were accessible to the masses, and without their simplicity, we could never have reached the level of adoption we now have. See the argument over the MEDIA vs. IMG tag from way back for a good example of that. However, now, that additive simplicity is holding us back.
What we need is a language with flow control, variables, functions, templating, the whole 9 yards. Not just on top of HTML & CSS, but as part of it. So we can dynamically change the size of page elements based on other page elements (think layout managers) without making incredibly complex and highly specific css for a variety of media screen sizes. Common features like centering a dialog box or a three-column display with header and footer sections shouldn't be a hack you need to ferret out, that may behave badly with long or short pages. It'd be nice to explicitly link action management with page elements and avoid much of the code required to identify actors and route events. Heck, some sort of built in asynchronous request mechanism might be nice, rather than having to write custom javascript each time.
What we don't need is another life support extension to a markup language.
There's a few parts to a banking system, and the 'core' - is usually on a mainframe. The name 'core' in this context means "The software system used to store financial account data" - a database, for the most part. It stores the account data, and occasionally a few other pieces of information, but mostly the account data. Account data never really changes, so neither have these "core" systems. They're also like 20-30 years old, and so rarely break anymore. They're time-tested.
However, modern banks do not use that system, or usually even a mainframe system, to perform the processing. First of all, most banks won't do real time transactions. They make it look like real time to end-users, but on the back-end, there's delays. Instead, they have proxy authorization systems that try to manage the minute-to-minute data and authorize transactions with the info they have. When you use an ATM and you're not at a bank location - or you are, but it's a distant branch, you're probably using a proxy authentication. If you're sneaky, and you've got someone on the other side of the country, you could probably withdraw the 'same' money twice before the proxies reconcile. Eventually it'll catch up to you, but it may work in the short term.
So we've got proxy authenticators that talk to each other and the core and keep the day's running total.
Then comes the clearance systems. This is the end of day processing where all account transactions are reconciled. These started out on mainframes, but most modern banks have moved off them, leaving only the core behind. It might be because the clearance processors are updated fairly frequently. They need to be aware of things like when (and how) to charge fees, customer plans that allow usage rates, taxes, court-mandated child support deductions, all sorts of things. Any time there's a new plan or program or account type or feature, basically, the clearance nodes need to be updated.
So when do they do their thing? The clearance process will go through all the proxy authorization nodes and do all the accounting that is needed, and when confirmed by a bank employee, and only then, finally updates the core with the new values. This usually happens once a day, but busy banks may be running it 4 or more times (though I rarely hear of anyone even using 2, except for special circumstances where it's manually triggered)
So I'd guess that, probably, the processing is not on a mainframe. It's probably in a cluster of servers running the clearance processing, and that they do reasonably frequent updates. Some percent of the time, these updates are what causes the "loss" of data in the first place.
So, I used to write banking software for a living, and that included being in the damage control team when things went south. Which they did. A lot. Which were brought to the technical staff's attention, without fail, every friday at 4 PM - but I digress.
This isn't really a big deal.
This sort of thing happens on almost a daily basis. I'd say that 1 in every 500 banks "loses" a day's transactions each week. From hardware failure to networking problems, to someone entering bad data to simple bugs in the software (usually data-dependent and hard to source), and even an occasional overwrite from a backup. Something breaks.
Once we had an FI lie about their data center setup - it wasn't redundant, offsite, certified, or even a datacenter. They just had some machines running in their basement. Imagine our surprise when they called up wanting us to (remotely) fix their servers which were under 6 feet of water during a flood.... again, I digress.
The thing about these transactions is they're not really lost. Nothing really goes missing.
See, all financial software is super keen on accounting. I don't mean that in a strictly 'add up the numbers' way, but in an auditing way. There are logs upon logs. Using your ATM card to withdraw $20 probably generates around, oh, I dunno, 30-40 log messages, depending on how it's routed. There's a log of the transmission and response in each node along the way, using a standardized protocol. It's a severe pain in the butt, but even if a system goes down forever, we can regenerate those logs from the other systems. It's a great deal of effort, especially to preserve the sequence order, and it's tedious, but it can be done.
This could easily account for the initial delay in fixing things.
Not only that, all these sorts of systems are very keen on sequence-order processing, so if it's just the case that the end of day processing (clearance) system went down/had a bug/etc and none of the transactions were finalized, then they'll just stack up. Once they get that system up again, it'll start processing them again. It might take longer due to a large backload, but it'll eventually complete.
98% of the time, the only people that notice are companies waiting on a payroll to go out, and most of them are happy enough to accept the financial institution's admission of fault. For a day or two at least. Why this one made the paper, I can't tell you. Probably a customer was savvy enough with social media and decided to burn the bank. I guess they should just be happy the public in general doesn't realize how many problems and how much actual work goes into making banking seem reliable and secure.
I saw the article linked with things some folks want, and hated most of it. Vehicles? Really?
Here's what I'd like;
- Companion characters & character development done by the Bioware teams (I'm gonna ignore the low-average quality from the Dragon Age Inquisition game). Bethesda Softworks does an admirable job with environment and atmosphere, but their NPC's are generally flat, with a few exceptions. Companions most of all. Multiple companions might be nice, Companion quests, idle-time squawking/interparty squawking, scenarios providing different options with different companions.
- Combat that always feels like a challenge, and not just in a ninja-monkey way where their stats scale to your level. Perhaps limit the character growth and equipment attributes in a D&D 5'th ed sort of way. Adjustable, though (see 'customization' below)
- They rock at allowing mods, but having a truly made-for-third-parties-without-a-debugger-running sort of script evaluation (profiling), execution, merging and management system would be swell. Knowing a module was going to crash - or even just which mod caused the crash - is a big help.
- Enough customization to allow different play styles, not just different difficulty levels. For example, the New Vegas optional 'hardcore' mode requiring food, drink and sleep, but perhaps with a checklist of 'collectables' and an easy combat or excessive loot for folks who are more interested in achievements than someone who wants to soak up the atmosphere. This includes any time a dev said "But that won't work on console" - make it an option. None of this dumbing things down just because it has to run on a console.
- That mod thing up there? I'm putting it here again because I like mods.
- Oh, and an easy way to add songs to a playlist rotation, not requiring a mod with a new radio station, necessarily.
You may know the quote: "Premature optimization is the root of all evil," but the whole quote in context explains why it is so:
"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." - Donald Knuth
In fact, it takes an experienced eye to know when and where to optimize, to identify that critical 3%. In the meanwhile, novices are so worried they'll miss it that they try to overoptimize everything, not having the experience of maintaining programs written in that way.
So when you see that sort of pattern abuse, especially naming classes after patterns, like -Facade, -Decorator, -Adapter, -Mediator, (and -Mixin depending on the language) realize that what you're dealing with is a novice's code, written by an amateur with no clear understanding of the entirety of their job, and adjust your expectations accordingly.
That may explain why it's still around even after it's been technologically eclipsed, in a similar vein to Java.
They're not around because they're easy to read or the choice language or any other criteria that would make sense to a developer, but rather because there was a corporate investiture. Money spent means more to a business than other metrics.
The whole "convention over configuration" theme is maddening, because if you don't know the conventions - or haven't figured out the new conventions that a particular project uses to drive execution and data flow, you're going to be lost. What is gained in brevity is added cost on the maintenance side. I once spent 2 days helping someone troubleshoot a currency formatting issue on a RoR app; someone had created a mixin to extend a base string class method, in a file describing a service. Fixing the code took all of 5 minutes, but finding it took forever.
With Java, it's worse now than it used to be. A decade ago, your major threat to readability was someone with pattern prejudice; those who ended up encapsulating everything in a factory-factory to factory to interface to abstract to etc, etc, etc, making every data object change require changes to 5-10 files just to surface the changes to the end methods using it, just for the sake of doing it.
Today you've got stuff like Spring. Ever try to do a manual, non-runtime code analysis of a project of decent size that heavily uses Spring, even where it's not necessary (like interfaces that will only ever have a single implementation)? Or worse, have you guys seen the OSGi development model? Let me put it this way; imagine using the original J2EE bean model, with home and remote interfaces and all that, only we've decided to use CORBA as our architectural focus. So every method can be a dependency-injected service-provided module, ready for you to call the service factory and grab an instance of the feature you want, which incidentally makes static analysis of code by humans more or less impossible.
Yes, I understand the concepts for these features, and OSGi actually has some neat capabilities (that we've had since the mid 90's via similarly laborious mechanisms like CORBA or more often, DCOM), but they do detract heavily from both the readability and maintainability of the code. If a new developer can't determine the execution or data flow for a given scenario in a few minutes, it's going to be onerous for them to maintain the system. That pain for the benefit of what we all know is the patent myth of polymorphism; that every project is going to have a need for unplanned sibling code modules in the future - it doesn't seem like a good trade off to me.
I've started to really appreciate code that I can use tools - often just the 'find in files' feature of an IDE - to trace through execution and data flow. It's becoming less and less common, and sourcing and correcting bugs is taking up more and more of my time because of that rarity. I sometimes look back on 'tricky' C code that uses/abuses pointer arithmetic and requires complex memory management, and I feel wistful for when it was that simple, that you could know what the code was actually doing... aww crud. I'm like a few years away from complaining about those darn kids on my lawn, aren't I?
Java was the first language on the scene that came with a top-to-bottom marketing rollout. They had certification, training, professional tutorials and classes, sponsored competitions, commercials and corporate branding, full page ads in trade magazines, and a one-size-fits-all modular system of components to mix and match and fit every need, and you could even become certified as a java evangelist - that used to be a real job at some corporations.
Once they got solid buy-in, well, companies are loathe to change unless there's either a pain point or a generational technology gap, and sometimes not even for the latter (see batch processing mainframes running cobol and RPG programs).
So that's what it is. If anything, as the language matures many people actually want to get away from readability; they want annotations and dependency injections controlled by some non-centralized mechanism, such that you must either rely on everyone else who worked on the product getting things 'right' and just magically working without your understanding of other processes (a theoretical goal of good OO development), or more often, you must understand all the code running at all times. Try doing a manual analysis of a good sized project that relies heavily on Spring, or worse, an OSGi project.
Projects using those features are not self-documenting code. Tracing execution or data flow is extremely difficult. All I can say is at least it's not Ruby, Objective C, or Smalltalk.
So, no, it's not readability. There's a good subset of programmers who are strongly against readability. It's money, plain and simple. It's a corporate investment, and that's all there really is to it.
Open source code faces a special obstacle when it comes to quality documentation. By the very nature of the ecosystem, open source projects derive from the needs of those who are directly contributing to it; the experts, in fact, and thus any artifacts the project produces will be based on their requirements, not those of casual users. It's not only required, but expected that in most cases, a user will be knee deep in the lower level details and have a high level of proficiency and knowledge of not only the system, but contingent details.
In fact, I can remember a time when creating a user-friendly webpage for open source projects - one with bubbly callouts, animated page features, and tutorial videos - was seen as some sort of sell out - proof of corporate sponsorship or the like. We know that providing more than just a link to the source code and a paragraph or two is a significant effort, much less organizing all the information in an immediately useful way is a huge time and effort sink. That's time and effort that could have gone into bug fixes or feature enhancements. For the intended users, it's sort of a waste.
Yeah, chicken and the egg situation here, good docs = more users, more users = more need for good docs, but that's only the case if 'large number of users' is a higher priority than bug fixes or feature enhancements (and it very well may be!).
So it'd be nice to have better documentation, and not just hope that stack overflow will be there with a solution, but like the example citing non-english speakers - is that part of the scope of the documentation? Is that the primary target? Is it worth our actual time? And if so;
- How do we motivate people to write good documentation?
- How do we attract quality technical writers?
- How do we know when we've written good documentation/what are the criteria?
- How do we know how to limit our documentation? How much is enough, and how much is too little?
- How can we place an explicit value on that documentation, vs. other concerns like bugs and feature development?
The article pointed out some good arguments for better documentation, but barely touched on the bigger problem - how do we get people to actually write it, and how do we write it once we've decided to.
I read about this in a business journal article on IP law. I have searched many times for this on the net, and I could not find it. The relevant details were:
The employee worked for a utility or utility hardware company, either power or phones. The case was brought somewhere in the 98-2000 time frame, though that's just a rough guess. This specific case was cited in a different article relating to the Jacobsen v. Katzer case, regarding strange uses & abuses of IP law, but I can't find that article either.
I believe that the issue with making him finish the work was multipart:
1) He was nearly done
2) The seizure was treated like a subpena for records - something which is allowed to incur a burden on the provider (who is allowed to charge a reasonable fee)
3) At the time, the court could not understand any other mechanism for transfer of the IP other than making him finish his work and turn it over
4) The prosecution made a case that because the company has no knowledge or insight to this work at the time, that it would be easy for the ex-employee to...something something willful maliciousness... and make the product he turns over useless. That includes providing an incomplete product without instructions for completion, etc. So he was required to make it a professional quality product with documentation and non-obfuscated source code, on fairly short notice, a build environment, plus be available for support.
I'm pretty sure that he was to receive a set amount of remuneration for his work, something similar to his previous job, but he'd have no right to the code afterwards.
Today this may be done a bit differently, but fairly draconian IP ownership laws were the standard pre-2000, and few individuals had the ability to stand up to large companies in courts, even for what appears to be insane requirements. Just take a look at the non-compete clauses from that time.
This is very easy. By default, anything you create - or even imagine - during business hours or in execution of your duties is 100% owned by the company. In fact, if you produce something at home and you can't show clean room separation between systems and code between your personal code and your work code, you're not likely going to keep the rights to that either.
You know that part of the employment process where they ask you to list all your prior works? This is them giving you a chance to CYA. Granted, the legalese on that page usually states that you're allowing them to use it for free in perpetuity if you include it in any of your work at the company, but that makes perfect sense Think utility libraries you carry around with you from job to job. They don't want to own them, but they can't risk having their products 'poisoned' by arbitrary licensing.
In fact, there's even a case where a guy had an idea, spoke to a co-worker about it, discussed it with his immediate superior and they decided not to follow up on it. After he quit the company, he started work on it himself, and was getting ready to finish/sell it, when he was sued by his prior employer. Because it had been 'developed' (thought of, even if it was never written down) on company time, the judge sided with the company and full ownership was given to them. He had to finish the program and deliver it and the mechanisms required to build and distribute it to them, without malicious sabotage Forced to write code for free, for a product the company didn't even want.
So! The only way this is really going to work for you is if you speak to your legal team and management.
I have, in the past, approached my manager(s) and asked permission to work on side jobs which were clearly and 100% outside of the scope of my current job; working on banking applications while I was writing automobile inventorying software, and was given permission. Got a signed statement, and I was good. Did open source work on the side as well, for a game engine, again, no problems.
However, it's extremely unlikely that anything you do at work will be allowed to be owned by you. No company likes giving away potential revenue and adding competitors with insider knowledge. I mean, really unlikely. Like, I can't even comprehend how you think it's a real possibility. Getting the company to go along with an open source thing might be one possibility, but an employee getting ownership?
Think of it this way: You work as a mechanic in a garage. You have access to all the tools and equipment there. You decide that you'll start your own business, in that garage, fixing cars, but you'll keep all the money instead of giving it to your employer, while still using his equipment and space. You still expect him to pay you for the hours you're working there.
Can you really see this happening? If so, you may need to lay off the cough syrup, cause we're all worried about you.
That's kind of the point I was making. If you are willing to work for less than you need to survive in an area, then they likely won't care about your age when making hiring decisions, because you'll be a bargain.
I worked as a contractor at IBM a few years back. They had just changed their hiring policies to basically three types for engineering positions:
1. Foreign workers in areas with low cost of living that are paid location-adjusted wages
2. New hires fresh out of college (preferred if they interned with IBM previously) for about 30% below market cost
3. Individuals who were known in their field of study - acknowledged experts, basically, obviously a rarity.
Everyone else was being pushed out or required to do the work of the experienced engineers who were pushed out on top of their own work, while training their own replacements. As in, "You can still work for us, but you have to move to brazil and accept a location-adjusted $27k/yr equivalent".
This resulted in the majority of incoming employees being extremely young, low 20's, zero experience, with the older individuals being skipped not because of age, but because they were not willing to pay real market value for them, when they can get cheap labor that can be trained up to the same point for 1/3'd of the cost. Especially when the young kids are willing to put in 60 hour weeks because they don't have competing obligations.
This wasn't a case of IBM being evil; they were just following the industry trends. I've seen other companies do the same thing.
It's not that they aren't hiring people because of their age. If anything, they'd love to hire those experienced professionals. They just want them to work for below average starting pay for a zero-experience, fresh college grad. Someone with 20 years of experience is expensive, after all, and budgets are quarter to quarter - not 5 years down the road. Hard to justify long term ROI in just a single level of management. Got 20 years of experience and you're willing to work for 40k in San Jose? You'll have no problems finding a job. Want a more reasonable 150-200k? Well, there's 5 guys in vietnam that will do your job for 20k a pop, and that makes up for the loss in efficiency - on paper, at least.
This is a common misconception. You cannot "get your anger out" by indulging in it. Hitting a pillow or screaming until you're hoarse, or verbally thrashing someone on the internet does not make you act like a gentle person the rest of the day.
If that was the case, you'd see most of our professional athletes; especially hockey players, football players, and boxers, as some of the most gentle, even-keeled people that ever existed.
If anything, this makes us more used to binge angry, as we acclimate to it physiologically and psychologically. Perhaps this is why it seems those above atheletes are prone to excessive and often illegal violence on and off the field.
I don't personally like jquery mobile because I don't like one-page apps, or indeed, any framework that dictates how I organize my application. Though it may be an unpopular opinion, I dislike the whole convention over configuration theme that's popped up during the RoR popularity phase. Not only can my IDE write out any boilerplate, but I can also search for the linkage, and all that without making 80% of my application easy at the expense that 20% will be hard or impossible.
Now, most of the applications I end up writing are fairly complex, don't need fancy animated transitions from page to page, don't require touch/multitouch interfaces, so maybe I'm not the intended audience.
I suppose if you're writing a fairly simplistic application, like say, showing a bus schedule or reading a review, it'll be fine. I wrote a jquery mobile app once that's just a series of short forms that produce sets of calculations at the end, which made really complex calculations for initial settings on industrial tools accessible to an operator without requiring a shift manager or technician to come over and reset things for them. I remember it still being quite a pain pulling values from other pages and doing some of the calculations. I especially disliked how my nagivation logic ends up in the javascript, rather than in the backend with the rest of my controller & business logic.
Slashdot Mirror
The science to it is basically this: When sitting, your metabolism slows, you burn less calories, and all the fun that goes with that - higher likelihood to be overweight, thus higher blood pressure, cardiac issues, and so on. We have studies that prove this too.
So, don't sit right? Well, standing isn't very good for you either, not for long periods of time. We're lacking any really hard science on what the optimal time period really is, although we know that it's variable depending on the person. We do know that you're more at risk for immediate health problems from long periods of standing rather than sitting (which results in longer term, less immediate issues). For example, even with a soft gel mat, after a few weeks, one stander ended up with medical conditions.. They're not just an anomaly either; back pain, carotid atherosclerosis - a circulation issue, varicose veins, pinched nerves, and more are associated with long periods of standing.
The fact is that we don't really know how much standing is enough to ward off the dangers of sitting, and worse, we don't know how much standing is too much and will result in health problems. There's probably an optimal healthy point, but we don't have any studies that show where that optimal healthy point is on average, much less how it needs to be adjusted for an individual.
It's also important to note that positive claims associated with standing desks that are not associated with physical well-being, such as increased mental capacity, creativity, memory, attentiveness, productivity and so on, are largely due to recirculating personal anecdotes, which we know carry a strong bias and use no objective measures for comparison. What few studies there have been show no evidence of benefit, nor of detriment. In a obvious note though, they show that treadmill or cyling desks DO reduce attention and productivity by a significant amount, and they haven't been shown to result in any impressive health gains either - users average weight loss of only about 3 lbs a year, for example, and that's about the only study you'll find on the subject!
What this all means is that, scientifically speaking, advocating for the health benefits of a standing desk is about the same as advocating for the health properties of barefoot running, clay cleansing (or really any cleanses, including charcoal, pickle juice, and others), and the whole genre of fad diets.
There's no scientific proof that shows they are a net benefit, which means you shouldn't assume they provide one. They are just standard junk science until then - taking a fact or finding and running with it past the point and on to speculation and pure fantasy. In fact, these are more akin to the fad diets, in that you're not only not gaining a benefit, you're that much more likely to cause harm to yourself. Standing desks are the new fen phen.
If you're worried about staying healthy, skip the fads and just add an exercise plan to your day. Take a 40 minute walk at lunch. Maybe workout a few times a week. Eat healthy, but more important in most western countries, eat a proper portion size. That's all it really takes.
Just to name a few:
1. The water pan is there to keep the brisket moist, which not only helps keep the meat from drying out, which also aids in smoke penetration (which is where the flavor comes from). It's not there to catch drippings. In the case of an egg smoker, it's also there to reduce the impact of different burns.
2. Offset smokers seem to be preferred by most "pitmasters"; direct heat really means you're grilling, not smoking, and that means you're mostly cooking over coals, rather than producing consistent smoke with an open-flame fire for the duration of the burn, and that means you're not getting enough flavor.
3. The "fuel" - given rather short shrift here - is one of the more important parts of bbq, and very hard to automate. Green wood, seasoned, large chunks or small, each has an impact on the immediate heat, the curve that the heat follows as it burns, and of course, the flavor via the smoke.
4. 220 lbs of brisket is decent, but good brisket places do 2000 lbs a day. If you're looking for something of quality instead of, well, acceptable, you're going to need to spend more time experimenting to figure out how to make a good brisket.
5. In order to have a chance to regulate the temperature well - and not keep cycling through blasts of heat and cooling - they'll need multiple temp probes, and an awareness of the outside temp and humidity as well, since ceramic insulation or no, the external environment will play a huge factor.
6. If the flat - the lean part of the brisket - is falling apart when you pick it up, the brisket has been overcooked. It means the point is going to have the consistency of pudding - or it's been destroyed entirely and is completely dry. It's harder to avoid this in a direct-heat smoker rather than an offset.
It should probably look like this. I remember seeing that shot in Franklin's book, Franklin Barbecue: A Meat Smoking Manifesto ... which yes, sounds pretentious, but since he's lauded as the best BBQer in texas several times over, and that book is #1 in BBQ & Grilling books on Amazon, maybe he's allowed to be a bit pretentious. Go get that book if you're at all interested. Apparently fact checked by Harold McGee.
There's more things I could pick apart too. I know, I'm sounding like a BBQ snob, but the fact is that I'm not very good at cooking it, and I haven't had a lot of experience. However, like any geek, I did my research. I read around. I checked things up on the internet. I talked to cooks. I volunteered at some cookoffs. I think I have just barely enough experience to recognize when someone else is doing it poorly. Anyone who's done this at all isn't going to be very worried about this invention, since, well, the parts that you can automate are the parts that are least likely to affect whether your brisket is going to taste good. You may as well have just stuck it in an oven with a few blocks of aromatic wood in a water pan underneath at 275 for an hour and a half per lb.
C'mon folks. This is basic stuff when working with any hazardous machinery. This is entirely a human error, and the 'robot' aspect of it is unimportant. The word 'machinery' would have been less provoking. It's about the same as saying "Factory worker dies after jumping into industrial tire shredder with insecure controller hardware". The controller has nothing to do with it.
Granted, Europe doesn't have the same OSHA requirements as the US, but still, it's pretty obvious.
If you're not familiar with this concept, here's a summary & scenario.
Summary: You use a device to physically stop the operation of the machine that requires a lock, and then you keep the key to that lock with you so only you can re-enable the machine.
Situation: You need to rewire half a building. You shut down the power and lock the panel so no one can turn it on. You start work and now your hands are full of wire. At the same time, a co-worker's air compressor loses power because it's plugged into that downed grid, he comes over and wants to turn it back on, but since you have the only key, he can't. As a result, you stay alive. Alternatively, you don't lock the panel, and your co-worker electrocutes you.
Put more succinctly than I could. It's a popularity contest, little more.
If you're doing front end web development, at some point, you're going to have to become good at Javascript.
You've got all these different frameworks where everything gets abstracted 3 redirections deep into a pseudo MVC layer populated with promise events and callback system that work well for 80% of the job and make 20% incredibly hard, and STILL in the end ties into the DOM, and is just as breakage prone, all the while explicitly demanding you adhere to their code organization because that way they can encode configuration into class names and function invokations and all of them claiming the other is bad not because of intrinsic issues but because they don't make the same ideological architectural choices like one-page-apps or putting business logic (including navigation!) in pages - even though it's more predicated on popularity than functionality, and ALL of that built on top of the mess that is Javascript and you are well and truly sunk my friend. Not even a run-on-sentence has enough space to cover all the horrible stuff that lies out there for the aspiring web developer.
So I recommend learning Javascript. Once you have a good strong feel for the fundamentals, once you've treated Crockford's "JavaScript: The Good Parts," the same way as you've done with K&R's "The C Programming Language," and you're solid on the basics, THEN jump off into these new worlds of overly pretentious web designers delving into their first languages and claiming you can't write a decent site without coffeescript, haml, and sass. So you can put them in their place, or at least, so you can understand how much they're complicating what is, after all, not that difficult of a thing. Even experienced developers write really, seriously completely awful code with Javascript, thinking they'd doing a decent job because they didn't invest time and energy to understand why they're not.
The only problem is that Javascript is bad. I like learning by examples, but that is so not the way to go with Javascript. Examples abound - but they're more than likely to be bad examples. There's reference books, like "Javascript: The Definitive Guide," but they're not great for learning. So what I do is tell people to learn jQuery first.
With jQuery and a few minutes, they can pick up the basics. Someone who already knows CSS or writes code for a living should feel productive in less than a full work day. It's easy, it's fast*, it handles browser differences**, there are well documented examples of how to use each feature on the jQuery doc pages, and best of all for me - it's non intrusive, so you can fit in the new vanilla javascript you're slowly picking up in, without needing to learn any framework specific configurations or magic function naming or guessing why it's not calling a method because it's not been added to the object prototype by your pesudo controller registration.
For me, I hate frameworks that are all-or-one solutions. Big heavyweight*** frameworks that tell you "This webpage is now a ____ application". First, they never are perfect solutions, and second, they always make some percent easier at the cost of making the rest painful. I think when learning a new language, especially if you've already got one or more under your belt, forcing someone to do it your way, or making familiar patterns or constructs hard is a huge detriment. Besides, how can you expect someone to learn if they're not allowed to get it wrong? You end up with folks who don't understand the importance of things like memory management if they never had to do it, and how useful are they during crunch mode?
So, yeah. Learn jQuery. Learn dom traversal and manipulation. Learn event registration. Learn AJAX. Try out some animations. Write a plugin or two. Many of these things are appearing in modern browsers now, but once you understand the concept, the basics that are endemic to web development, and you can be productive, then you'll have the grace time needed to properly learn actual Javascript. Then you get out your
I'm not sure where to start. I'd like to do a point-by-point, but there's no need. The issue on my part is very simple:
People should be judged based on their own merits, not the color of their skin or their gender, not based on the socioeconomic class they're from, not by handicap or caste or because someone has a quota or a chart that shows an irregular curve they'd like to smooth out.
What you're calling 'social fairness' is actually quite unfair to society or individuals.
The issue with affirmative action-type policies is that it is saying, in no uncertain terms, capability is not as important as quotas. That folks who have been deemed capable should not only not be given opportunity, but that opportunity should be given to someone who has not been deemed capable. That can't be considered fair in any society - and before you complain, consider that this is exactly the policies apartheid & theocratic governments and pre-civil war US used. People judged based on their skin color, religion or other minority status, rather than their ability.
This is not just a matter of treating people as individuals instead of a member of a group as an ethically and morally correct stance. Treating people who are not capable of a job as qualified and allowing them to occupy important positions is a danger to all of society. How that can be lost on you, I don't know. This is the very root of the problem with nepotism and cronyism!
Perhaps this straw man scenario might help: "Your doctor isn't technically qualified to perform your gall bladder surgery, but we needed someone from a low income family on staff to round out the numbers. So ... yeah... good luck in there!"
I don't think we're there yet with doctors, but it is already happening with police, firefighters, and other emergency personnel. How can you justify this by saying that it's acceptable or worse, preferable simply because some arbitrary binning of the population doesn't turn out equal numbers. I can't wait till someone notices there's not enough people with low intelligence being recognized as geniuses and tries to fix that. ... yes I know it's absurd, but the whole concept seems crazy to me.
I was listening to NPR the other day, and this story popped up: Examining Race-Based Admissions Bans On Medical Schools .
The short version is; certain states have ruled that colleges are not allowed to consider race as part of their admissions criteria, and medical schools are noticing that black and latino graduation numbers have decreased since then.
The intent was to focus on merit-based evaluations. Seems noble, right? We want the best doctors we can get. However, the effect appears to be to reduce the number of minority students admitted. This, of course, has people outraged, and scrambling to find ways to work around the system - like sending recruiting teams to primarily-black or latino high schools, and hoping that will increase the applicant numbers.
What shocked me is that everyone is dancing around the race issue (and only certain races; not, for example, Indian or other asians). Everyone agrees the minority graduation numbers have dropped because individuals from a given group don't actually meet the admissions criteria. They're not qualified to be students or doctors. That apparently hundreds or thousands of people's failing grades were ignored because of their race. That prior to the no-race rule, doctors, in this case, were not necessarily the most well qualified individuals for the job. In fact, some significant percentage of them should not have been allowed in.
This trend isn't new either. When I was a lifeguard back in the 90's, the requirements changed from being able to swim a specific distance in a certain time, to removing many of these fitness requirements altogether. The reason? It was apparently unfairly eliminating people with poor physical ability or handicaps. The new focus was to do all the lifeguarding from the side of the pool: hooks, ropes, and life preservers.
Heck, just last month there was a minor kerfuffle about fire departments force- and expedited-promotions of minorities over whites.
I can't help but see this girls-only computer science focus being another of these sorts of ill-considered plans, where capability takes a back seat to minority inclusion and political correctness. Sure, it's not as vital as our doctors, firemen, and lifeguards, but it's the same line of thought. In our rush to be politically correct and all inclusive, we mistake equality for equally fair, and it serves no one well except those promoting our differences.
Am I the only one who thinks this is crazy? Like Harrison Bergeron crazy? I can't be the only one, right?
Studies seem to indicate that this is largely due to the constantly shifting cultural landscape which says, for example, women make better psychologists and biologists now, whereas 30-40 years ago, that was not the case. It's not that men in general are hardwired to avoid nursing and want to be garbage men, and women are selected to be secretaries and beauty stylists, but rather, the culture they're brought up in acts as a filter to determine what jobs should be held by which gender based on cultural norms, based on no objective differences in ability or merit at all.
So it is the case that our culture is steering gender-based career selection, in an irrational, non-directed way. The bigger issue is: does it really matter all that much? Is it actively or passively hurting anyone? Would forcing equality, especially when it requires working counter to cultural values, really be any better?
My personal belief is that it won't, but there are a lot of loud, angry people out there who seem to think otherwise.
I'm assuming the article is referencing this data: http://www.randalolson.com/wp-.... That is a pretty striking curve, though there are two interesting points to make:
- Women have made consistent gains year to year in nearly every engineering and "hard science" field, some more than others (biology is a standout)
- The absolute number of women CS graduates is actually increasing as well - it's just that male graduate numbers are increasing at about twice the rate.
However, contrary to your claim, there are many, many people trying to asking why. There's lloads of speculation, but the ones that seem most reasonable to me point to a large scale cultural shift that considers women better youth educators (pre highschool teachers), psychologists, journalists, biologists, pharmacists, and a large drive into the agricultural job market. Studies have shown - as referenced elsewhere - that these cultural values are imposed early, and one of the major sources is the female child's mother, though popular media also drives some of this. This goes the other way too, with the cultural acceptance of male interest in video games potentially acting as a familiarization gateway to CS careers.
But really, we're only investigating ~that~ question because we're trying to solve a bigger one: How do we get more women with CS degrees and/or working as software engineers? If the studies are right, it seems the best way is to train new parents to stop limiting their children.
More important in my mind though: is that a valuable goal?
There is some greater potential for creativity in problem solving - meaning things like faster software, better interfaces, when you include a diverse body of people, but it's hard to measure that potential, or determine if it's been realized. There's nothing to indicate that given two individuals, one can be expected to perform any better than the other based on gender in this field, so it seems that if you myopically focus on one with a disregard as to their actual merits, you run the risk of hiring the worse performer.
Generally, I'd say that this is more of a non-issue. As we raise an increasingly tech-savvy generation, and negative cultural stigma of IT workers fall to the side, I think we'll naturally see more women in the field, as the work is fairly light and the pay is reasonable. At the same time, I don't think deliberately pushing towards that goal really serves the public or companies or women in any real way, and it may even be hurting it, as per the article's original question about gender stereotypes.
This is not anything we're not already doing, the difference is that right now it's incredibly difficult to do well, and the result is an intractable mess. Markup - and CSS is just an externalized form of markup - lacks any real power. It's simplistic, which makes it approachable, but not very flexible or adaptive. In order to achieve even simple goals, we're using fairly complex and increasingly obscured and inflexible markup. When that fails, we turn to javascript to provide liquid layouts that work, and cart this baggage of per-page non resusable javascript around with us, all of it ready to break as soon as we make any changes - or use a viewport we didn't consider.
What I'm suggesting is that we provide the same controls we have for generating a user interface for local software in web browsers. That means being able to programatically adjust layouts, styles, etc, without having to wrap javascript around them to provide for a responsive interface or implement common layout requirements. It means doing all the things we already do, but in a way that increases readability, maintainability and future modifications.
Basically, it means internalizing something like flash, without the proprietary nature and other detriments.
That's pretty much what this WebAssembly bytecode would do, and what I've been advocating for.
What you're talking about seems to have ... absolutely no basis on either the article or my comment. I'm not even sure what it is you're suggesting. Letting other people run any program on your computer through your web browser? That does sound stupid.
I have also been saying this for years.
It's nice that HTML and CSS were accessible to the masses, and without their simplicity, we could never have reached the level of adoption we now have. See the argument over the MEDIA vs. IMG tag from way back for a good example of that. However, now, that additive simplicity is holding us back.
What we need is a language with flow control, variables, functions, templating, the whole 9 yards. Not just on top of HTML & CSS, but as part of it. So we can dynamically change the size of page elements based on other page elements (think layout managers) without making incredibly complex and highly specific css for a variety of media screen sizes. Common features like centering a dialog box or a three-column display with header and footer sections shouldn't be a hack you need to ferret out, that may behave badly with long or short pages. It'd be nice to explicitly link action management with page elements and avoid much of the code required to identify actors and route events. Heck, some sort of built in asynchronous request mechanism might be nice, rather than having to write custom javascript each time.
What we don't need is another life support extension to a markup language.
This depends on a number of issues.
There's a few parts to a banking system, and the 'core' - is usually on a mainframe. The name 'core' in this context means "The software system used to store financial account data" - a database, for the most part. It stores the account data, and occasionally a few other pieces of information, but mostly the account data. Account data never really changes, so neither have these "core" systems. They're also like 20-30 years old, and so rarely break anymore. They're time-tested.
However, modern banks do not use that system, or usually even a mainframe system, to perform the processing. First of all, most banks won't do real time transactions. They make it look like real time to end-users, but on the back-end, there's delays. Instead, they have proxy authorization systems that try to manage the minute-to-minute data and authorize transactions with the info they have. When you use an ATM and you're not at a bank location - or you are, but it's a distant branch, you're probably using a proxy authentication. If you're sneaky, and you've got someone on the other side of the country, you could probably withdraw the 'same' money twice before the proxies reconcile. Eventually it'll catch up to you, but it may work in the short term.
So we've got proxy authenticators that talk to each other and the core and keep the day's running total.
Then comes the clearance systems. This is the end of day processing where all account transactions are reconciled. These started out on mainframes, but most modern banks have moved off them, leaving only the core behind. It might be because the clearance processors are updated fairly frequently. They need to be aware of things like when (and how) to charge fees, customer plans that allow usage rates, taxes, court-mandated child support deductions, all sorts of things. Any time there's a new plan or program or account type or feature, basically, the clearance nodes need to be updated.
So when do they do their thing? The clearance process will go through all the proxy authorization nodes and do all the accounting that is needed, and when confirmed by a bank employee, and only then, finally updates the core with the new values. This usually happens once a day, but busy banks may be running it 4 or more times (though I rarely hear of anyone even using 2, except for special circumstances where it's manually triggered)
So I'd guess that, probably, the processing is not on a mainframe. It's probably in a cluster of servers running the clearance processing, and that they do reasonably frequent updates. Some percent of the time, these updates are what causes the "loss" of data in the first place.
So, I used to write banking software for a living, and that included being in the damage control team when things went south. Which they did. A lot. Which were brought to the technical staff's attention, without fail, every friday at 4 PM - but I digress.
This isn't really a big deal.
This sort of thing happens on almost a daily basis. I'd say that 1 in every 500 banks "loses" a day's transactions each week. From hardware failure to networking problems, to someone entering bad data to simple bugs in the software (usually data-dependent and hard to source), and even an occasional overwrite from a backup. Something breaks.
Once we had an FI lie about their data center setup - it wasn't redundant, offsite, certified, or even a datacenter. They just had some machines running in their basement. Imagine our surprise when they called up wanting us to (remotely) fix their servers which were under 6 feet of water during a flood. ... again, I digress.
The thing about these transactions is they're not really lost. Nothing really goes missing.
See, all financial software is super keen on accounting. I don't mean that in a strictly 'add up the numbers' way, but in an auditing way. There are logs upon logs. Using your ATM card to withdraw $20 probably generates around, oh, I dunno, 30-40 log messages, depending on how it's routed. There's a log of the transmission and response in each node along the way, using a standardized protocol. It's a severe pain in the butt, but even if a system goes down forever, we can regenerate those logs from the other systems. It's a great deal of effort, especially to preserve the sequence order, and it's tedious, but it can be done.
This could easily account for the initial delay in fixing things.
Not only that, all these sorts of systems are very keen on sequence-order processing, so if it's just the case that the end of day processing (clearance) system went down/had a bug/etc and none of the transactions were finalized, then they'll just stack up. Once they get that system up again, it'll start processing them again. It might take longer due to a large backload, but it'll eventually complete.
98% of the time, the only people that notice are companies waiting on a payroll to go out, and most of them are happy enough to accept the financial institution's admission of fault. For a day or two at least. Why this one made the paper, I can't tell you. Probably a customer was savvy enough with social media and decided to burn the bank. I guess they should just be happy the public in general doesn't realize how many problems and how much actual work goes into making banking seem reliable and secure.
I saw the article linked with things some folks want, and hated most of it. Vehicles? Really?
Here's what I'd like;
- Companion characters & character development done by the Bioware teams (I'm gonna ignore the low-average quality from the Dragon Age Inquisition game). Bethesda Softworks does an admirable job with environment and atmosphere, but their NPC's are generally flat, with a few exceptions. Companions most of all. Multiple companions might be nice, Companion quests, idle-time squawking/interparty squawking, scenarios providing different options with different companions.
- Combat that always feels like a challenge, and not just in a ninja-monkey way where their stats scale to your level. Perhaps limit the character growth and equipment attributes in a D&D 5'th ed sort of way. Adjustable, though (see 'customization' below)
- They rock at allowing mods, but having a truly made-for-third-parties-without-a-debugger-running sort of script evaluation (profiling), execution, merging and management system would be swell. Knowing a module was going to crash - or even just which mod caused the crash - is a big help.
- Enough customization to allow different play styles, not just different difficulty levels. For example, the New Vegas optional 'hardcore' mode requiring food, drink and sleep, but perhaps with a checklist of 'collectables' and an easy combat or excessive loot for folks who are more interested in achievements than someone who wants to soak up the atmosphere. This includes any time a dev said "But that won't work on console" - make it an option. None of this dumbing things down just because it has to run on a console.
- That mod thing up there? I'm putting it here again because I like mods.
- Oh, and an easy way to add songs to a playlist rotation, not requiring a mod with a new radio station, necessarily.
You may know the quote: "Premature optimization is the root of all evil," but the whole quote in context explains why it is so:
"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
- Donald Knuth
In fact, it takes an experienced eye to know when and where to optimize, to identify that critical 3%. In the meanwhile, novices are so worried they'll miss it that they try to overoptimize everything, not having the experience of maintaining programs written in that way.
So when you see that sort of pattern abuse, especially naming classes after patterns, like -Facade, -Decorator, -Adapter, -Mediator, (and -Mixin depending on the language) realize that what you're dealing with is a novice's code, written by an amateur with no clear understanding of the entirety of their job, and adjust your expectations accordingly.
That may explain why it's still around even after it's been technologically eclipsed, in a similar vein to Java.
They're not around because they're easy to read or the choice language or any other criteria that would make sense to a developer, but rather because there was a corporate investiture. Money spent means more to a business than other metrics.
Agreed.
The whole "convention over configuration" theme is maddening, because if you don't know the conventions - or haven't figured out the new conventions that a particular project uses to drive execution and data flow, you're going to be lost. What is gained in brevity is added cost on the maintenance side. I once spent 2 days helping someone troubleshoot a currency formatting issue on a RoR app; someone had created a mixin to extend a base string class method, in a file describing a service. Fixing the code took all of 5 minutes, but finding it took forever.
With Java, it's worse now than it used to be. A decade ago, your major threat to readability was someone with pattern prejudice; those who ended up encapsulating everything in a factory-factory to factory to interface to abstract to etc, etc, etc, making every data object change require changes to 5-10 files just to surface the changes to the end methods using it, just for the sake of doing it.
Today you've got stuff like Spring. Ever try to do a manual, non-runtime code analysis of a project of decent size that heavily uses Spring, even where it's not necessary (like interfaces that will only ever have a single implementation)? Or worse, have you guys seen the OSGi development model? Let me put it this way; imagine using the original J2EE bean model, with home and remote interfaces and all that, only we've decided to use CORBA as our architectural focus. So every method can be a dependency-injected service-provided module, ready for you to call the service factory and grab an instance of the feature you want, which incidentally makes static analysis of code by humans more or less impossible.
Yes, I understand the concepts for these features, and OSGi actually has some neat capabilities (that we've had since the mid 90's via similarly laborious mechanisms like CORBA or more often, DCOM), but they do detract heavily from both the readability and maintainability of the code. If a new developer can't determine the execution or data flow for a given scenario in a few minutes, it's going to be onerous for them to maintain the system. That pain for the benefit of what we all know is the patent myth of polymorphism; that every project is going to have a need for unplanned sibling code modules in the future - it doesn't seem like a good trade off to me.
I've started to really appreciate code that I can use tools - often just the 'find in files' feature of an IDE - to trace through execution and data flow. It's becoming less and less common, and sourcing and correcting bugs is taking up more and more of my time because of that rarity. I sometimes look back on 'tricky' C code that uses/abuses pointer arithmetic and requires complex memory management, and I feel wistful for when it was that simple, that you could know what the code was actually doing. .. aww crud. I'm like a few years away from complaining about those darn kids on my lawn, aren't I?
Java was the first language on the scene that came with a top-to-bottom marketing rollout. They had certification, training, professional tutorials and classes, sponsored competitions, commercials and corporate branding, full page ads in trade magazines, and a one-size-fits-all modular system of components to mix and match and fit every need, and you could even become certified as a java evangelist - that used to be a real job at some corporations.
Once they got solid buy-in, well, companies are loathe to change unless there's either a pain point or a generational technology gap, and sometimes not even for the latter (see batch processing mainframes running cobol and RPG programs).
So that's what it is. If anything, as the language matures many people actually want to get away from readability; they want annotations and dependency injections controlled by some non-centralized mechanism, such that you must either rely on everyone else who worked on the product getting things 'right' and just magically working without your understanding of other processes (a theoretical goal of good OO development), or more often, you must understand all the code running at all times. Try doing a manual analysis of a good sized project that relies heavily on Spring, or worse, an OSGi project.
Projects using those features are not self-documenting code. Tracing execution or data flow is extremely difficult. All I can say is at least it's not Ruby, Objective C, or Smalltalk.
So, no, it's not readability. There's a good subset of programmers who are strongly against readability. It's money, plain and simple. It's a corporate investment, and that's all there really is to it.
Open source code faces a special obstacle when it comes to quality documentation. By the very nature of the ecosystem, open source projects derive from the needs of those who are directly contributing to it; the experts, in fact, and thus any artifacts the project produces will be based on their requirements, not those of casual users. It's not only required, but expected that in most cases, a user will be knee deep in the lower level details and have a high level of proficiency and knowledge of not only the system, but contingent details.
In fact, I can remember a time when creating a user-friendly webpage for open source projects - one with bubbly callouts, animated page features, and tutorial videos - was seen as some sort of sell out - proof of corporate sponsorship or the like. We know that providing more than just a link to the source code and a paragraph or two is a significant effort, much less organizing all the information in an immediately useful way is a huge time and effort sink. That's time and effort that could have gone into bug fixes or feature enhancements. For the intended users, it's sort of a waste.
Yeah, chicken and the egg situation here, good docs = more users, more users = more need for good docs, but that's only the case if 'large number of users' is a higher priority than bug fixes or feature enhancements (and it very well may be!).
So it'd be nice to have better documentation, and not just hope that stack overflow will be there with a solution, but like the example citing non-english speakers - is that part of the scope of the documentation? Is that the primary target? Is it worth our actual time? And if so;
- How do we motivate people to write good documentation?
- How do we attract quality technical writers?
- How do we know when we've written good documentation/what are the criteria?
- How do we know how to limit our documentation? How much is enough, and how much is too little?
- How can we place an explicit value on that documentation, vs. other concerns like bugs and feature development?
The article pointed out some good arguments for better documentation, but barely touched on the bigger problem - how do we get people to actually write it, and how do we write it once we've decided to.
I read about this in a business journal article on IP law. I have searched many times for this on the net, and I could not find it. The relevant details were:
The employee worked for a utility or utility hardware company, either power or phones. The case was brought somewhere in the 98-2000 time frame, though that's just a rough guess. This specific case was cited in a different article relating to the Jacobsen v. Katzer case, regarding strange uses & abuses of IP law, but I can't find that article either.
I believe that the issue with making him finish the work was multipart: ...something something willful maliciousness ... and make the product he turns over useless. That includes providing an incomplete product without instructions for completion, etc. So he was required to make it a professional quality product with documentation and non-obfuscated source code, on fairly short notice, a build environment, plus be available for support.
1) He was nearly done
2) The seizure was treated like a subpena for records - something which is allowed to incur a burden on the provider (who is allowed to charge a reasonable fee)
3) At the time, the court could not understand any other mechanism for transfer of the IP other than making him finish his work and turn it over
4) The prosecution made a case that because the company has no knowledge or insight to this work at the time, that it would be easy for the ex-employee to
I'm pretty sure that he was to receive a set amount of remuneration for his work, something similar to his previous job, but he'd have no right to the code afterwards.
Today this may be done a bit differently, but fairly draconian IP ownership laws were the standard pre-2000, and few individuals had the ability to stand up to large companies in courts, even for what appears to be insane requirements. Just take a look at the non-compete clauses from that time.
This is very easy. By default, anything you create - or even imagine - during business hours or in execution of your duties is 100% owned by the company. In fact, if you produce something at home and you can't show clean room separation between systems and code between your personal code and your work code, you're not likely going to keep the rights to that either.
You know that part of the employment process where they ask you to list all your prior works? This is them giving you a chance to CYA. Granted, the legalese on that page usually states that you're allowing them to use it for free in perpetuity if you include it in any of your work at the company, but that makes perfect sense Think utility libraries you carry around with you from job to job. They don't want to own them, but they can't risk having their products 'poisoned' by arbitrary licensing.
In fact, there's even a case where a guy had an idea, spoke to a co-worker about it, discussed it with his immediate superior and they decided not to follow up on it. After he quit the company, he started work on it himself, and was getting ready to finish/sell it, when he was sued by his prior employer. Because it had been 'developed' (thought of, even if it was never written down) on company time, the judge sided with the company and full ownership was given to them. He had to finish the program and deliver it and the mechanisms required to build and distribute it to them, without malicious sabotage Forced to write code for free, for a product the company didn't even want.
So! The only way this is really going to work for you is if you speak to your legal team and management.
I have, in the past, approached my manager(s) and asked permission to work on side jobs which were clearly and 100% outside of the scope of my current job; working on banking applications while I was writing automobile inventorying software, and was given permission. Got a signed statement, and I was good. Did open source work on the side as well, for a game engine, again, no problems.
However, it's extremely unlikely that anything you do at work will be allowed to be owned by you. No company likes giving away potential revenue and adding competitors with insider knowledge. I mean, really unlikely. Like, I can't even comprehend how you think it's a real possibility. Getting the company to go along with an open source thing might be one possibility, but an employee getting ownership?
Think of it this way: You work as a mechanic in a garage. You have access to all the tools and equipment there. You decide that you'll start your own business, in that garage, fixing cars, but you'll keep all the money instead of giving it to your employer, while still using his equipment and space. You still expect him to pay you for the hours you're working there.
Can you really see this happening? If so, you may need to lay off the cough syrup, cause we're all worried about you.
That's kind of the point I was making. If you are willing to work for less than you need to survive in an area, then they likely won't care about your age when making hiring decisions, because you'll be a bargain.
I worked as a contractor at IBM a few years back. They had just changed their hiring policies to basically three types for engineering positions:
1. Foreign workers in areas with low cost of living that are paid location-adjusted wages
2. New hires fresh out of college (preferred if they interned with IBM previously) for about 30% below market cost
3. Individuals who were known in their field of study - acknowledged experts, basically, obviously a rarity.
Everyone else was being pushed out or required to do the work of the experienced engineers who were pushed out on top of their own work, while training their own replacements. As in, "You can still work for us, but you have to move to brazil and accept a location-adjusted $27k/yr equivalent".
This resulted in the majority of incoming employees being extremely young, low 20's, zero experience, with the older individuals being skipped not because of age, but because they were not willing to pay real market value for them, when they can get cheap labor that can be trained up to the same point for 1/3'd of the cost. Especially when the young kids are willing to put in 60 hour weeks because they don't have competing obligations.
This wasn't a case of IBM being evil; they were just following the industry trends. I've seen other companies do the same thing.
It's not that they aren't hiring people because of their age. If anything, they'd love to hire those experienced professionals. They just want them to work for below average starting pay for a zero-experience, fresh college grad. Someone with 20 years of experience is expensive, after all, and budgets are quarter to quarter - not 5 years down the road. Hard to justify long term ROI in just a single level of management. Got 20 years of experience and you're willing to work for 40k in San Jose? You'll have no problems finding a job. Want a more reasonable 150-200k? Well, there's 5 guys in vietnam that will do your job for 20k a pop, and that makes up for the loss in efficiency - on paper, at least.
This is a common misconception. You cannot "get your anger out" by indulging in it. Hitting a pillow or screaming until you're hoarse, or verbally thrashing someone on the internet does not make you act like a gentle person the rest of the day.
If that was the case, you'd see most of our professional athletes; especially hockey players, football players, and boxers, as some of the most gentle, even-keeled people that ever existed.
If anything, this makes us more used to binge angry, as we acclimate to it physiologically and psychologically. Perhaps this is why it seems those above atheletes are prone to excessive and often illegal violence on and off the field.
I don't personally like jquery mobile because I don't like one-page apps, or indeed, any framework that dictates how I organize my application. Though it may be an unpopular opinion, I dislike the whole convention over configuration theme that's popped up during the RoR popularity phase. Not only can my IDE write out any boilerplate, but I can also search for the linkage, and all that without making 80% of my application easy at the expense that 20% will be hard or impossible.
Now, most of the applications I end up writing are fairly complex, don't need fancy animated transitions from page to page, don't require touch/multitouch interfaces, so maybe I'm not the intended audience.
I suppose if you're writing a fairly simplistic application, like say, showing a bus schedule or reading a review, it'll be fine. I wrote a jquery mobile app once that's just a series of short forms that produce sets of calculations at the end, which made really complex calculations for initial settings on industrial tools accessible to an operator without requiring a shift manager or technician to come over and reset things for them. I remember it still being quite a pain pulling values from other pages and doing some of the calculations. I especially disliked how my nagivation logic ends up in the javascript, rather than in the backend with the rest of my controller & business logic.
Really though, it's up to personal preference.