You have to realize how politicized and religiously bent the texas government is. Any vetting group would be made up of specifically hand-picked individuals who would meet certain religious and political views. It would be about as academic as the Westboro Baptist Church.
They've been saying this since the origin of the Luddites in the early 1800's!
Technology is a force multiplier. It allows one person to perform the work of many. Historically, instead of increasing unemployment, it's done the opposite - creating larger numbers of jobs, especially in positions that can't exist without a large-scale economy technology provides. The ability to make a shirt via a machine, thousands of times faster than by hand necessitates buildings for the machines, a distributed sales force, logistical concerns like transport and storage, advertising, etc. Each technological advance may reduce the number of employees in that explicit role, but increases the total number of jobs, the total hours of work required by an order of magnitude or better.
However, there's a limit. We haven't reached it yet, but it's there, looming in the distant future. At some point, we will reach peak technological assistance. Everything that can reasonably be automated will be. We'll literally have no need for all the people in the world to be working, much less the ability to employ them all.
Automated tellers at fast food joints is not the limit, by the by. I'm guessing we're still hundreds of years away.
The hard part isn't getting there though. The trick is going to be how we handle the runup to this post-scarcity world. At some point in the interim, we'll still consider money to have a direct relationship to work done via services and goods, and thus be necessary for comfortable living, but a significant minority will be unemployed and poor.
That 15 hour day you're referencing, that's going to be like the end times. It means either we have a revolution and start all over, or we jump the hurdle and enter into some sort of Star Trek-like world where we just accept that not everyone should work as a condition of having a comfortable life.
Personally, I don't see it happening in a positive way. The average human just isn't wired to be altruistic, and it's about the furthest from what our governments are set up to give us.
Engineer doesn't necessarily have to mean "Someone with professional certification who performs a task in a pre-designated method begat wholly by one's predecessors."
The more general definition is simply "creator of systems".
More to the point, we do have professional certifications, we have professional societies, and while we may not be represented by a national-level federation with standardized capabilities, we still present a much-in-demand skillset at a variety of levels. If I had to guess, I'd say that the engineering certifications are themselves simply a relic of the times; one part hold-over from when unions were necessary plus one part CYA legal protection via standardized best practices. These are two things that are (not yet) needed in the software development world, and I can't see the former ever being relevant.
Additionally, as engineer itself is not a protected term like Dentist, or Doctor, anyone can use it. In the US, the best you could says is that you're a NCEES certified engineer, but that's not a requirement to work as an engineer, nor to claim that you are one. In fact, most states have their own requirements beyond the NCEES, and you couldn't claim to be a licensed engineer without meeting/those/ requirements. Or in other words, there's various licensing and certification bodies out there, with different goals, requirements, and levels of measure. Just like there are for programmers...
All that being said, I actually prefer the term Software Developer or Software Programmer. Not for any of the reasons listed in the article why we're not engineers, rather, I just think Developer or Programmer are more accurate terms. Though I detest the term the author coined, "Engineerwashing*," I agree with his list of motivations why it is used. It's basically to make it seem fancier, neater, more professional. It's what I put on my resume because it's a better match for job postings than developer or god forbid, programmer now-a-days.
Then again, I liked the original definition of the term "hacker," and only recently have stopped correcting people by saying, "You mean "Cracker," right?" when they used it in the more modern form. I get it. We're not France though - language is a continually evolving thing, and you've got to keep up with the times.
The fact is, we're now all Software Engineers. That's what we do is called now.
This wasn't about the ethics of D&D. This was one person's opinion about how alignment should be handled in an RPG, presented as factual, objective instructions.
For the fun of it - and countering his/suggestions/ - how about these definitions:
"Alignment is how you treat everyone who is not in your party." "Alignment is a rough pigeonholing of your moral and philosophical outlook, used to qualify for magic spells and effects, and can change on a day-to-day basis based on your actions or justifications for actions, but should restrict you in no way - it's a classification, not an attribute." "Alignment is a silly thing, and it's implementation is overly restrictive, making it difficult to role play realistic, complex characters. So we're not using it in this campaign."... and to counter individual suggestions about the impact of alignment:
There's no need to make every crime result in moral reflection or in-game (negative) consequences - this is a game, for entertainment, not explicitly a forum for ethical reformation.
It's okay to have a world with full populations of cartoonish, evil beings and villainous stereotypes who can be abused in a number of ways, with joy and abandon.
Since the goal is fun, you can have fun 'beating the game' without even descending into roleplaying, much less worrying about how an arbitrary classification is supposed to straight-jacket your player into behaving in a single, stereotypical way.
You're thinking of SXSW Music. SXSW has split into 3 parts: Music, Film, and Interactive. This is SXSW Interactive. SXSW Music doesn't even start until SXSW is over.
You've got a cell phone with a phone. You're handing these out to people, physically.
So take a picture of your friend holding the book. Maybe even save it to a specific location like 'books lent out'. Works with singles and stacks. No tricky software, no custom solutions, no worries about QR codes or scanners or online web interfaces.
Works for more than just books, too. Video games, clothes, power tools, etc.
How many other engineers are going to be expected to know and maintain this? Ones you have on staff? Are you making sure to hire for folks who know Rust? If you have one, is your ops team up to supporting applications written in Rust, familiar with the errors and can handle it? What's the life expectancy of the app? Ever going to need to port it in the future?
Don't forget to factor in the bus factor, when you lose a whole engineer.
Lots of folks end up missing these and you end up with mysterious legacy code the business completely depends on for day to day ops that no one knows or understands. Heck, the other day, I was asked to unlock a windows NT laptop because it was the only known repository of source code for an app that was written over a decade ago - hopefully.
Sarcasm aside, guns are not meant to 'immobilize a person'. They're meant to kill. The goal of a LEO using a gun is to eliminate a threat, by killing it. That's not only to protect the LEO, but also others. As far as that goes, guns are pretty good. Not great, but not bad.
Yep, I can explain why some places have lower violent crime and such. It/is/ a sort of brainwashing, but it's very long term and unguided; it's the impact of growing in a given area and being subject to it's mores and cultural specifics. This is the route that we'll need to go to actually make it safe, shown as possible by demonstration of these other less violent cultural groups. In short, when it's considered culturally unacceptable to use violence or commit crimes, we'll push the stats down far more than with laws and punitive punishments.
Remember though, the goal here is to come up with something that replaces the gun and is better at protecting police and 'immobilizing people' without hurting them. Assume all guns are removed from the hands of law enforcement. Now, how do you achieve the above objective without forcing some freedom-stripping compliance?
Sadly, there is no good mechanism for forcing a specific culture on a group of people in a polite way. The only way it's ever worked in the past is via conquering and forcing it at the end of a metaphorical (and all too often, literal) blade. You can pick psychological or physical force, but one way or another, it comes down to the elimination of personal choice and whether it's justified for the good of the ruler or the good of society, it's all the same in the end to the man on the street.
Like I stated before, you're gonna need to force change on the culture, and the only manageable way to select for the preferred outcome is, indeed, by force.
Look at North Korea. Their police rarely have a need for guns, and in fact, most conflicts that occur seem to be at the behest of the government and not the other way around. Their policing is proactive, reducing the number of conflict events.
You just have to remove all personal freedoms and justify everything as being better for society, for a given definition of better. Our two major political parties in the US have already been making inroads on this, we just need to take it a step further.
Sarcasm aside, guns are not meant to 'immobilize a person'. They're meant to kill. The goal of a LEO using a gun is to eliminate a threat, by killing it. That's not only to protect the LEO, but also others. As far as that goes, guns are pretty good. Not great, but not bad.
As far as sci fi solutions go, even the most imaginative writers of our time cannot separate risk from policing with access to any fantasy tech or magic possible. Look at Star Trek with the ability to detect and identify individual life forms from light years away, a transporter that can move people thousands of miles, a weapon that can stun nearly any life form into unconsciousness with no risk to the target (which makes you wonder why they don't just use it on all suspects from the start), and they still can't manage prisoner transfers 10 out of 10 times, where the guy is already in chains!
Nope, you're going to have to go the brainwashing/programming route.
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.
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.
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.
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.
- 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? Yo
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!
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.
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.
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.
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.
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.
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.
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.
Slashdot Mirror
You have to realize how politicized and religiously bent the texas government is. Any vetting group would be made up of specifically hand-picked individuals who would meet certain religious and political views. It would be about as academic as the Westboro Baptist Church.
They've been saying this since the origin of the Luddites in the early 1800's!
Technology is a force multiplier. It allows one person to perform the work of many. Historically, instead of increasing unemployment, it's done the opposite - creating larger numbers of jobs, especially in positions that can't exist without a large-scale economy technology provides. The ability to make a shirt via a machine, thousands of times faster than by hand necessitates buildings for the machines, a distributed sales force, logistical concerns like transport and storage, advertising, etc. Each technological advance may reduce the number of employees in that explicit role, but increases the total number of jobs, the total hours of work required by an order of magnitude or better.
However, there's a limit. We haven't reached it yet, but it's there, looming in the distant future. At some point, we will reach peak technological assistance. Everything that can reasonably be automated will be. We'll literally have no need for all the people in the world to be working, much less the ability to employ them all.
Automated tellers at fast food joints is not the limit, by the by. I'm guessing we're still hundreds of years away.
The hard part isn't getting there though. The trick is going to be how we handle the runup to this post-scarcity world. At some point in the interim, we'll still consider money to have a direct relationship to work done via services and goods, and thus be necessary for comfortable living, but a significant minority will be unemployed and poor.
That 15 hour day you're referencing, that's going to be like the end times. It means either we have a revolution and start all over, or we jump the hurdle and enter into some sort of Star Trek-like world where we just accept that not everyone should work as a condition of having a comfortable life.
Personally, I don't see it happening in a positive way. The average human just isn't wired to be altruistic, and it's about the furthest from what our governments are set up to give us.
Engineer doesn't necessarily have to mean "Someone with professional certification who performs a task in a pre-designated method begat wholly by one's predecessors."
The more general definition is simply "creator of systems".
More to the point, we do have professional certifications, we have professional societies, and while we may not be represented by a national-level federation with standardized capabilities, we still present a much-in-demand skillset at a variety of levels. If I had to guess, I'd say that the engineering certifications are themselves simply a relic of the times; one part hold-over from when unions were necessary plus one part CYA legal protection via standardized best practices. These are two things that are (not yet) needed in the software development world, and I can't see the former ever being relevant.
Additionally, as engineer itself is not a protected term like Dentist, or Doctor, anyone can use it. In the US, the best you could says is that you're a NCEES certified engineer, but that's not a requirement to work as an engineer, nor to claim that you are one. In fact, most states have their own requirements beyond the NCEES, and you couldn't claim to be a licensed engineer without meeting /those/ requirements. Or in other words, there's various licensing and certification bodies out there, with different goals, requirements, and levels of measure. Just like there are for programmers ...
All that being said, I actually prefer the term Software Developer or Software Programmer. Not for any of the reasons listed in the article why we're not engineers, rather, I just think Developer or Programmer are more accurate terms. Though I detest the term the author coined, "Engineerwashing*," I agree with his list of motivations why it is used. It's basically to make it seem fancier, neater, more professional. It's what I put on my resume because it's a better match for job postings than developer or god forbid, programmer now-a-days.
Then again, I liked the original definition of the term "hacker," and only recently have stopped correcting people by saying, "You mean "Cracker," right?" when they used it in the more modern form. I get it. We're not France though - language is a continually evolving thing, and you've got to keep up with the times.
The fact is, we're now all Software Engineers. That's what we do is called now.
This wasn't about the ethics of D&D. This was one person's opinion about how alignment should be handled in an RPG, presented as factual, objective instructions.
For the fun of it - and countering his /suggestions/ - how about these definitions:
"Alignment is how you treat everyone who is not in your party." ... and to counter individual suggestions about the impact of alignment:
"Alignment is a rough pigeonholing of your moral and philosophical outlook, used to qualify for magic spells and effects, and can change on a day-to-day basis based on your actions or justifications for actions, but should restrict you in no way - it's a classification, not an attribute."
"Alignment is a silly thing, and it's implementation is overly restrictive, making it difficult to role play realistic, complex characters. So we're not using it in this campaign."
There's no need to make every crime result in moral reflection or in-game (negative) consequences - this is a game, for entertainment, not explicitly a forum for ethical reformation.
It's okay to have a world with full populations of cartoonish, evil beings and villainous stereotypes who can be abused in a number of ways, with joy and abandon.
Since the goal is fun, you can have fun 'beating the game' without even descending into roleplaying, much less worrying about how an arbitrary classification is supposed to straight-jacket your player into behaving in a single, stereotypical way.
Sorry, meant to type "Until SXSW Music is over".
You're thinking of SXSW Music. SXSW has split into 3 parts: Music, Film, and Interactive. This is SXSW Interactive. SXSW Music doesn't even start until SXSW is over.
There's also 7 different exhibitions: http://www.sxsw.com/marketing/...
First by cancelling the panels due to threats, then by reinstating them due to threats!
The lesson to learn here kids: threats works!
You've got a cell phone with a phone. You're handing these out to people, physically.
So take a picture of your friend holding the book. Maybe even save it to a specific location like 'books lent out'. Works with singles and stacks. No tricky software, no custom solutions, no worries about QR codes or scanners or online web interfaces.
Works for more than just books, too. Video games, clothes, power tools, etc.
How many other engineers are going to be expected to know and maintain this? Ones you have on staff? Are you making sure to hire for folks who know Rust? If you have one, is your ops team up to supporting applications written in Rust, familiar with the errors and can handle it? What's the life expectancy of the app? Ever going to need to port it in the future?
Don't forget to factor in the bus factor, when you lose a whole engineer.
Lots of folks end up missing these and you end up with mysterious legacy code the business completely depends on for day to day ops that no one knows or understands. Heck, the other day, I was asked to unlock a windows NT laptop because it was the only known repository of source code for an app that was written over a decade ago - hopefully.
Exactly as I said above:
Sarcasm aside, guns are not meant to 'immobilize a person'. They're meant to kill. The goal of a LEO using a gun is to eliminate a threat, by killing it. That's not only to protect the LEO, but also others. As far as that goes, guns are pretty good. Not great, but not bad.
Yep, I can explain why some places have lower violent crime and such. It /is/ a sort of brainwashing, but it's very long term and unguided; it's the impact of growing in a given area and being subject to it's mores and cultural specifics. This is the route that we'll need to go to actually make it safe, shown as possible by demonstration of these other less violent cultural groups. In short, when it's considered culturally unacceptable to use violence or commit crimes, we'll push the stats down far more than with laws and punitive punishments.
Remember though, the goal here is to come up with something that replaces the gun and is better at protecting police and 'immobilizing people' without hurting them. Assume all guns are removed from the hands of law enforcement. Now, how do you achieve the above objective without forcing some freedom-stripping compliance?
Sadly, there is no good mechanism for forcing a specific culture on a group of people in a polite way. The only way it's ever worked in the past is via conquering and forcing it at the end of a metaphorical (and all too often, literal) blade. You can pick psychological or physical force, but one way or another, it comes down to the elimination of personal choice and whether it's justified for the good of the ruler or the good of society, it's all the same in the end to the man on the street.
Like I stated before, you're gonna need to force change on the culture, and the only manageable way to select for the preferred outcome is, indeed, by force.
The problem with using it is legal and ethical.
Look at North Korea. Their police rarely have a need for guns, and in fact, most conflicts that occur seem to be at the behest of the government and not the other way around. Their policing is proactive, reducing the number of conflict events.
You just have to remove all personal freedoms and justify everything as being better for society, for a given definition of better. Our two major political parties in the US have already been making inroads on this, we just need to take it a step further.
Sarcasm aside, guns are not meant to 'immobilize a person'. They're meant to kill. The goal of a LEO using a gun is to eliminate a threat, by killing it. That's not only to protect the LEO, but also others. As far as that goes, guns are pretty good. Not great, but not bad.
As far as sci fi solutions go, even the most imaginative writers of our time cannot separate risk from policing with access to any fantasy tech or magic possible. Look at Star Trek with the ability to detect and identify individual life forms from light years away, a transporter that can move people thousands of miles, a weapon that can stun nearly any life form into unconsciousness with no risk to the target (which makes you wonder why they don't just use it on all suspects from the start), and they still can't manage prisoner transfers 10 out of 10 times, where the guy is already in chains!
Nope, you're going to have to go the brainwashing/programming route.
English.
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.
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.
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.
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.
- 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? Yo
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!
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.
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.
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.
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.
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.
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.
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.