Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Comment Obligatory (Score 2) 429


In all seriousness: it's becoming difficult to communicate with all the acronyms, framework names being used as verbs, and corp-speak trickling into conversation, and this is with folks who are not necessarily expert communicators in the first place.

Comment Cell phone only configuration? (Score 1) 123

Am I alone here in thinking that's ... idiotic?

Okay, I have a heavy bias here. I don't use my phone much, and when I do, it's largely as a phone. I don't read my email on it unless I absolutely have to, I don't use it for web browsing, and it's not an entertainment platform for me, either games, music, or media. It's ... just a phone. Some of my coworkers see me as some sort of luddite for not hooking my work email into it.

Maybe in the future when we start using it as an ID and credit card replacement, I'd feel like locking in certain functionality wouldn't be a big deal, but ... networking hardware configuration? I can't even come up with a scenario where that's a good idea. Granted, this is a consumer device, but it seems like it's somewhat of a silly restriction.

Comment Re:MOOCs: my worst education experiences ever. (Score 1) 46

I was about to make the same arguments to see them already listed in this post.

Every single item that in the grandparent post appears to apply only to live and in person lectures. Long. Boring. Pacing unrelated to my personal comprehension speed - whether that was slow or fast. Unable to pause in the middle for any reason. The only thing I could take away was notes - assuming I could write down what was being shown on the board AND listen to the professor AND try to digest it all at the same time, all before they moved on and wiped the board clean.

None of them apply to video lectures which provides unparalleled freedom - as long as you're willing to take the initiative and follow through.

Comment Re:MOOCs: my worst education experiences ever. (Score 1) 46

Both forms require a lecturer who is good in his chosen medium, and more importantly, a student who is attentive and dedicated to learning. If you fail to provide both, you're going to have a bad time.

So I dismiss the idea that video can be 'boring and time intensive' offhandedly. So too may be normal lectures, to the student unprepared to dedicate themselves.

There are many flaws in in-person lecturing that video lecturing solves, the biggest of which is the 'pause', 'rewind', and 'skip ahead' buttons. With subtitles, we do away with accent/language issues. With online quizes and tests for comprehension, we get instant feedback and verification instead of continuing on to appease the 40-200 other students.

All of this, and we still allow for a question and answer via email, forum posts, or even live 'webinar' style office hours - with the benefit that the non-realtime questions and responses can be answered by a larger body of people (professor, ta, other students) without interrupting the lecture, and in a way that maximizes information density.

It may not be the most efficient mechanism when trying to teach a given high quality student, but it provably is if you ever mix even a single lowest common denominator student into any class.

Comment The romance of the code ninja (Score 4, Insightful) 114

- Silently checking in 12000 lines of code in the middle of the night and leapfrogging the entire development schedule by months.
- Spending 72 consecutive hours at the keyboard, sustained by caffeinated drinks and a desire to produce an end product that will make your users - and other programmers say 'Wow!'
- Delving into the voodoo and deep magic of a system, consuming it all and spitting it back out with ease, and being regarded with awe by your peers.

Yeah, these are awesome. The Story of Mel was an early encouragement to me; between it and the movie Tron, it put me on the path to being a software developer.

Lots of folks pointed out pro- arguments, so I won't cover those, but there are an awful lot of cons. 20 years plus into my career, I'm seeing some fatal flaws.

The first is the Bus Factor. A solo developer, whether in a group or not, does not facilitate the dispersal of knowledge. There's a difference between documentation - even the elusive technical documentation - and knowledge, and that gulf widens with each feature, bugfix, and release. In my experience, when a solo developer leaves - for whatever reason - it's often easier to start from scratch than try to maintain their software.

That leads us to the next issue, maintainability. As was described above, a solo developer can skip quite a bit; coding style, documentation, modularization, naming schemes, readability, unit testing, automated build and deployment, and so on. I've had to take over so many projects in my life that required more time to set up a working build and test environment than they did to fix the error I had been brought in to tackle. I used to carry a pack of cd's with precompiled versions of sed, awk, as, and other tools for various *nix platforms (and versions of those platforms) because these were often not just pre-requisites for the often complex script-based builds, but often only came in for-pay packages that weren't on the machine I was expected to work off of. I had a set of about 30 just for HP-UX alone (because you have no idea which version-specific behavior a given build relies on). Put it this way: every build required a port.

Of course, it's not just other people's code. I'd come back to something I wrote a year prior and it'd be horrible.

"Why did /THEY/ do this? Wait ... did I do this? Geeze, I USED to write bad code." - me, every. single. time.

I have a theory that only constant modifications to code keeps away the gremlins that cause bitrot. Leave a piece of code alone for a month, no commits (assuming you're even using version control), and they come in and crap all over your beautiful hacks and graceful architecture, rendering it just barely capable of doing what it was designed to do, and sometimes not even that. Yet, you write your code as if a team will handle it, losing most of the benefits of being a solo dev, and it's usable when you come back to it later.

Communication is next, and it ties into the maintainability above, but on a software development lifecycle level. When someone is silently making architectural changes and off doing their own solo thing, sure, they get a lot done. When you're completely by yourself, that's fine. What happens though, when you're doing solo development in a large company? Suddenly there's no code reviews, no understanding of department or organization architectures, or even just updates to them. Your code usually stands on the back of a whole architectural stack, and without two-way conversations, it isn't guaranteed to hold up. It's not just that you might accidentally reinvent the wheel - it's that you could do it wrong and limit the application (or have it die) later, with an expensive to fix systemic issue. Documentation fits in this category too - and why do documentation when you're a solo dev? You can always answer any question, right? You're available 24/7, so your users and other devs shouldn't need it ...

QA is another huge issue. It's very well established that the worst QA engineer is the developer that wrote the code to be tested. Even with tools giving you 100% code coverage, you're probably missing significant permutations just in your unit tests. Assuming you even do any of that. After all, as a solo developer, even unit tests lose most of their value - no code is modified outside your purview so you don't have to worry about regression or integration bugs, and there's no need for tests-as-requirement-documentation, since there's no need for documentation. All that's before we get to system, workflow, or use-case testing.

The last big con has to do with scaling. It's not that a single user can't manage a large codebase. It's that attention is a finite resource. What attention we apply to one set of features is necessarily removed from others. We can only keep so much in the front of our brain at a time, and often I see the solo developer fumble when it comes to interface/api interactions, thread management and synchronization, and other systemic problems.

So, yeah, I'm drawing a distinction between a solo developer who writes code like a solo developer and gains the benefits and detriments associated therein versus a solo developer who writes their code as if someone else is going to read it and eschews all the possible advantages. Personally, I feel everyone is better off if they'd be the latter, rather than the former, but I think the only way people understand this is via experience.

Comment Re:MOOCs: my worst education experiences ever. (Score 3, Interesting) 46

You seem to be saying that it's not easy to make the time, but what I'm hearing is, "I lack the discipline to schedule and prioritize my time and I need someone to explicitly provide me with that structure."

What's the alternative? Having an in-person class at a set time and location? That seems like it would take more time - and not of your choosing.

Until we get our lessons in pill form, there is no greater convenience to be had. You can learn literally any time you choose to. Get distracted? You can rewind and rewatch. Online quizzes, tests, and assignment submissions usually offer real-time feedback. You can be sitting on the toilet learning nuclear physics if it takes your fancy.

If you haven't got time for this, what are you doing on slashdot at all? You haven't got time for it either!

Comment Re:MOOCs: my worst education experiences ever. (Score 1) 46

I wrote about MOOCs back in 2012 when they were first starting to be a thing. I'll save you from reading with the summary: each course is different, your mileage may vary.

Today I find that the only real change is in the number of offerings. There are still experts in their field that are completely incapable of teaching (or at least, teaching using a primarily lecture based system), classes where the TAs appear to be more knowledgeable than the lecturer, and those few where all the stars align. Having an active and useful forum is just another factor you can't predict.

Of course, I disagree that learning is "about interacting with your fellow students," anyway. I think this is a potential benefit of some form or another, but that's not what learning is about. Without looking up the definition, I'd say that learning is the acquisition and comprehension of new ideas and skills. Saying instead that it's about forum postings - or forums with high value-for-content ratios - is like claiming your food tastes bad because you didn't like the restaurant decor.

If it IS a factor to you, you can always organize your own invite only unofficial forum or email list. I remember setting up many a majordomo list in the day, though I recall they were used more for sharing pat solutions and socializing rather than a forum to encourage learning. In my own experience, collaboration with my peers was rarely exceptionally useful. Office hours and the email address to the TAs were much better resources.

Comment Not my area of expertise but ... (Score 1) 87

What I've seen is that most companies are windows based and use active directory to centralize the vast majority of their permission management system. Almost every professional system out there then integrates into it via some LDAP mechanism, and it's usually relatively easy to switch in house apps over as well.

There's two other cases I've seen that aren't related explicitly to a person:
    - required local accounts
    - service accounts

There's always a lot of cases where you need a local account - like on networking hardware - but usually those are given general purpose accounts rather than linked with an individual. Service accounts, on the other hand, are used by software. Think database passwords. Companies usually end up using some sort of certificate authorization to access a database authentication token (be it username/password or other), and then use that to connect.

Depending on your company's password management policy, these last two cases can be hard to manage. Like rotating passwords on a periodic basis. I've yet to find any sort of commercial solution that works for these due to the specific nature of the problem - each scenario is unique enough that no general solutions work. As far as I've seen, in house software and dedicated IT teams tend to handle these.

Comment The politican is right (Score 1) 258

What happens in the public is and should be accessible by the public. That's the sort of law that allows us to have security cameras on homes and businesses, to take cell phone video of friends - or police. It's why we can tell someone what we saw, or try to reproduce a noise we heard, making a "pwooosh!" and spreading our hands for effect.

Did you know that the government isn't even doing the data aggregation? It's civilian companies that produce and distribute the hardware, that make deals with other companies and yes, government agencies, to mount them, and then they sell access to it.

The idea that data aggregation from public sources should be illegal, or that it should be illegal for the government to do are poorly thought out ideas indeed. What you're arguing against here is actually removing those rights from civilians, and you're going to have to use an extremely wide brush to do it.

That's because the only three important differences here are that this program records things in a way that's accurate, in a way that's reproducible, and that a machine sorts the information so that it's more immediately useful. None of those things have an intrinsic point where they cross a line that suggests harm is being done - there's nothing wrong with being 'too accurate' or 'sorted too well', and mixing the three together provides no obvious resolution. Lacking justification means you either restrict it all at the most base levels, or none of it - it's all equal. So you end up very quickly at what some would call a (logical) extreme.

Think where we'd be if we made it illegal for people to correlate data about racism or police brutality, or the ability to take a cell phone video, tag it, and upload it to a shareable location. This is the level that would be required to avoid aggregation of public data. You'd have to eliminate the ability to collect any data, any ability to correlate it, and you can't do that without removing the entire concept of public spaces being public in any way. ... and at that point, they'd be private to a government entity, and they'd still be able to surveil you while you lack any rights to do so in return.

Comment Re:It's not that it's illegal (Score 1) 231

In my limited experience and biased view, it seems most likely that the existent taxi companies got together to push the police force to perceive this as a problem out of scope of it's actual impact. Again, I wouldn't be surprised if it's because they bribed the police to tackle their competition. It's always seemed like bribes are required to make chinese society function, and depending on the venue, that's even more true in hong kong.

Comment It's not that it's illegal (Score 0) 231

It's that the proper palms were not crossed with silver. ...or being that it's Hong Kong, a glaring red envelope that everyone pretends doesn't exist.

That's how business works in China. You can be 100% legitimate, but without that bribe, you're going to jail. That's probably why only 5 drivers were arrested, instead of however many there actually were.

Comment Perl's problem: popularity, not functionality (Score 3, Interesting) 133

I've been around long enough to see Perl go from the glue of the internet to object of scorn. It's no longer the preferred tool of sysadmins or the easiest way to write web applications outside of raw C. I've had a good deal of time to consider why that's the case, and I keep circling back to it being an issue of popularity.

We like to think that we're engineers, scientists, deep thinkers, whatever - and that we as software devs therefore make sound evidence based judgements, at least more often than other disciplines. The fact of the matter is that we're just as led by emotions as anyone else. We have 'Holy Wars' over OSes and languages and frameworks, and what most of them boil down to is justification of personal preference more than anything else. Not features, not availability, just personal preference.

In that light, I've been seeing a lot of fad languages in the last decade or so. I usually refer to them as toy languages though that phrase may have a number of inaccurate definitions. Simply, they're a new toy to play with. Scripting languages are especially prone to this because they tend to have a lower barrier to entry. In recent memory, I seem to remember it going something like Ruby + RoR => Python => Scala => Javascript via node.js => and now the big thing I'm hearing about is R. The claim is that each one is so much better, but the reality of it is, it's just so much newer, and the differences in implementing identical functionality is not as important as the flash and sizzle. Even when the sizzle is backed by something useful, people stop paying attention once it stops. In fact, most of these languages have been around for a long time - several of them almost as old as Perl itself. They've just briefly become popular, not making any sort of surprising forward leap to become capable or more feature rich.

Of course, one big part of the popularity is maintaining buzz, and with what was effectively a 15 year hiatus from any real forward development, much less promotion, Perl dropped out of the limelight.

This is pretty standard though. People seem to forget so quickly; at one time, ColdFusion, Java Applets, Flash and PHP were the darlings of their day. Perl too.

Now, if someone were to take Perl 6, produce a framework for it that tried to force a remedial coding style (Python), require webapps follow a specific directory layout and naming convention (RoR, many JS webapps) as well as page templating (PHP, JSPs, Razor/Webforms, etc), add some human-friendly data query language features (Java Streams, C# LINQ), provide tools for automatic dependency search and import (Maven, Ruby Bundler), and then really play up the functional aspects of the language, and perhaps Perl will rise again too.

If that's really the features people are looking for. I deliver that line with only marginal sarcasm; I note that the number one complaint against Perl is ugly code, which we know is the domain of the author, not the language - and other languages 'fix' this by taking away developer agency.

Even without those new features, and though I don't use it as often, I still like the ole' "swiss army chainsaw," just a little bit more than these other choices. I guess you could say it was just a matter of personal preference.

Comment Re:There's a few problems here. (Score 1) 149

The problem is that with normal smoking, you're using split wood. It has a non-uniform size, and has been seasoned to different levels. Some may be greener than others, even in a batch of mostly seasoned wood. So some will burn hot and fast, and others slow and smoky (and some of those will be too smoky, and not fully combust, leading to bad tasting byproducts). A big piece of green wood won't burn the same as a small piece of dry wood, but by carefully adding the right wood at the right time - for the right external temp and humidity - and then further managing the airflow by various mechanisms such as extending the chimney or using fancy airflow redirectors in the bbq itself, a cook can actually manage the consistent heat with the right amount of aromatic smoke to enhance the flavor of the meat.

There's a lot of variables that go into play here, and there really is a whole science to it.

That being said, you could get uniform fuel for uniform heat. That usually means pellets. Of course, that in turn means that you're probably not going to be getting flavorful smoke, and that in turn, is the whole point of smoking in bbq.

You may as well just use an oven at that point though. It's easier to manage a consistent heat, and you don't have to worry about smoke. The quality of such a cook would very likely not suffer from injecting some 'liquid smoke' at that point, and it's so much easier.

Comment Net benefit of standing desks unconfirmed. (Score 3, Interesting) 340

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.

Comment There's a few problems here. (Score 3, Informative) 149

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.

When you make your mark in the world, watch out for guys with erasers. -- The Wall Street Journal