They way I figure it, using drag and drop to add code structures is just an eye-candied version of autocomplete in a text-based IDE, and it goes back to the original post: If they don't know what they are doing, they will suck at coding.
Does it matter at this stage? These tools are typically geared to kids younger than 3-4 grade (hell, the prime target would be 1st and 2nd graders.) To me, what matters at this stage is to ignite a sense of wonder and a sense that problems can be broken down into discrete, repeatable blocks: look, I can move the character 6 steps front, then 6 steps back, and making him say hello! Repeatedly, like forever! I wonder if I can make it do something else.
It shouldn't matter how the code itself is created.
As a professional software engineer, I disagree with that. It absolutely matters how the code was created. If you cannot create the code yourself from scratch and must rely instead upon templates, wizards and drag till you drop GUIs, you're doing it wrong.
Yes and No.
The No part: Most of us know conceptually how a compiler tool chain works, but I doubt most of us can bang the fundamental machine code that a compiler/linker generates. The tool chain is in essence nothing more than a very smart template and wizard system.
Similarly, I know how I could write a HTML templating system (say, something like JSP or Velocity), but I doubt I could get something that works like those in a reasonable amount of time.
Reliance of templates and wizards and drag-n-drop magic =/= not knowing how they work.
That is, a person needs to know the powers and limitations of those tools, and then leverage them appropriately for the right problems.
The Yes part: Too many people rely on wizards without knowing how to use them appropriately. Then they don't know how to untangle themselves from the monstrosities they create.
With that said, we must separate the issue of 1) people not knowing how to use high-level tooling from 2) the value of such tooling when applied correctly to the appropriate problems.
In this very specific case, we are talking about graphical tools to introduce kids to programming. Not adults, not full-fledged software engineers, but kids. Somewhere along the line we have completely lost perspective of what truly matters in this particular context.
We already have far too many people like that in this profession and the public wonders why their software is chock full of silly bugs, runs slow and reliability is poor. Using tools may be alright, if you know what you're doing, but if you could not work without them or don't understand what they're doing for you under the hood, you're just asking for trouble. When push comes to shove, there is no substitute for the text editor and the command line. Giving kids a false sense of achievement was a disaster for my generation with the whole "self esteem" fad and "everyone gets a trophy for participating". Unfortunately for our kids, the liberal dingbats who inhabit our public education system seem to have learned nothing from the 1980s and remain intent upon repeating the failures of the past. People like me succeeded in spite of public education, not because of it. Educators and their Code.org friends would do well to remember that.
It is insightful, perhaps you didn't understand the language it was written in?
In English it says, "What are they talking about, they just spewed a bunch of words without enough context to even identify which jargon set is being used. And the key word is a relatively new product/project, whose name is repeated umpteen times like it was written by a marketing droid, but is never explained even in context of the other jargon words."
Also, you just signed up yesterday, I can tell by your user id. You don't get to pine for my golden days of yesteryear, those are mine. Get your own, order them now and you can have them in a couple decades when you forget what it was really like.
LOL. Da'fuk? I have a submission on 2011, so obviously is not yesterday. Plus I had another account that goes back to 1998. But whatever, a post is worth by its content, not but the longevity of the account (and the fact that you use the later speaks more about you than about me.)
So much for BPMN, where you can actually create a significant amount of useful function just by doing that.
The thing about Mr. Yue's comments, however, is that he is completely missing the mission of all those drag-n-droppey efforts is not to equate cute little draggable blocks and call it coding. It is to get kids interesting.
I mean, for fucks' sake, we don't call kindergarten wooden counting blocks differential equations, do we?
Corporations are not people and should not ever be offended. Being rude to a company should not affect the way the company does business or whom it does business with. It is just Musk being a douche, because he's becoming arrogant.
When you are rude to a company, you are rude to the employees. Good managers and owners cut off shitty customers from the start to avoid that kind of shit from happening (which can have terrible consequences down the road - I have witnessed this. The customer is not always right.).
I am not saying this is exactly what happened in the story. I'm simply giving you a counter-argument to the above statement of yours.
Some of the "warning" -Wall checks and calls out are asinine. There not worth the time to "fix" just to make the compiler happy.
I cannot remember a concrete, very specific case from ages past where this was true. But in general, and after seeing a ton of code, if you start from the beginning with -Wall -Werror and don't let that shit go, it goes a long way towards maintainability.
Additionally, the moment you let that discipline go, things begin to go to shit. And before you know it, you have your compilation logs fulled with warnings that you cannot turn off because of the off change one of them might be relevant, and no way to go back and clean that shit up because the technical debt is too huge.
I hate working with projects were -Wall -Werror is not the norm for the bulk of source code. In the general case, warnings are latent errors and you might as well squash them without mercy before the creep out of your control.
Did a libtard SJW submit this story? They really hate free speech.
Free speech becomes hate speech. Speaking your mind becomes frowned on.
And this is bad because...? Welcome to life dude. Yes, speaking your mind becomes frowned on. Does that stops you from speaking your mind as a matter of principle? You need to really live in a state of repression to understand how precious it is to speak your mind, even if everyone else frowns on you.
Why Does Twitter Refuse To Shut Down Donald Trump?
I hate Trump, but I would never accept as appropriate for the Internet and the Media (and twitter is a de-facto part of the Media) to shut him down. Who the fuck could possibly ask for that?
Freedom of speech works both ways, and to uphold it demands from us to listen to that which is objectionable (and to deal with it with counter-arguments, not censorship.)
I understand that, in principle, Freedom of Speech does not forbid private media to censor free thought, unlike public media and government. But it is disenginuous to demand Twitter to censor Trump? Why? Because he is a misogynistic man-child who spouts vile racial shit to arouse those on the edge of nationalistic fervor?
Fuck that. Fuck your sensitivities. You don't censor that shit. You confront it heads on in the rhetoric arena. Let's face it, between 1/4 and 1/3 of the population believe the shit he says (and loves him because of the shit he says). Trumps speaks to them.
Do you think censorship is going to make that go away? No. In fact, it will make him a martyr to those idiots who go happy-bug-eye for him. You gotta let that shit come in the open. Let that stupidity be in the open for the world to see. Then attack it with counter-arguments, and with behavior as counter-examples.
To pussy up behind a wall of censorship that prevents to see the ugly realities of 'Murika, how the hell does that help?
He is having problems with his homework. You know, OP is just suffering from "little rebel without a cause with zero exposure outside the classroom" syndrome.
I've been bitten by more BitBucket outages than I've seen GitHub disruptions:p
Which is why you should have code bases in both (pick your primary in either, and keep the other one as a hot backup.) If a system is worth going through the trouble of constant availability and reliability, this is the only way to go.
As a user of source control in general- if you need an admin for it, you're doing it wrong.
No. You are doing it wrong (inexcusable) , or you are not working on a large scale system (understandable.). As your systems and teams grow in size and complexity, you need gatekeepers. And you need people in charge of doing sysadmin work, backups and stuff, including maintaining and backing up your main repositories.
Beyond a certain team size, it is not cost effective to have developers managing those resources. You want them to develop. Yes, you might have a few developers part-timing on those roles (or even better, have a close relationship with IT support, ala DevOps.)
But you need specialization. This specially true when your organization has source control platforms that cater not only to your projects, but other projects within the organization. Then you need centralized administration.
No ability to use the automated build system that pulls updates or source code exports from git tags at github. No configuration publication or web content updates with github based branches. Sharing code between repositories locally is still feasible, but loses the insurance that the code submitted to production has been submitted somewhere accessible to other programmers.
Email the deltas if you have to. And if you are in a real emergency, you can clone and upload your local copy into bitbucket.
We had a situation like that where we lost our infrastructure a couple of months ago. We couldn't code, we couldn't build, we couldn't do integration testing. Total blackout. Rather than waiting for Ops to bring everything back online, we stopped coding and migrated everything we needed on a different system. We lost a lot of history, but we were back on track.
It was either that on pick our noses during a down time twice as long.
Shit happens. If a team cannot find ways to work around it and make progress, however shaky it might be, I question their abilities. The fallacies of distributed systems applies to people, too.
Don't you have pull requests that need your attention?
Maybe there are pull requests that required attention before the outage, and that are in the works. Maybe you cannot commit, but you have more test cases to refine, more documentation to write. Oh yes, the stuff you have on your backlog, you can work on that too while you are at it. And if you really have to have someone get your changes (because shit, they are urgent), you can pull a worst-case scenario and e-mail your changed files to the appropriate recipient (because I'm certain your e-mail is not dependent on git.)
There is always work to be done. Unless you are complete unorganized and are unable to work independently, without peerage and supervision.
I refactored some of your code to use more inclusive variable names and expect you to respond by January 29th, otherwise we will demand you step down from your role as project maintainer.
CAPTCisHCisC: brothers
Because doubling down on the bat shit crazy makes your argument all the more plausible.
Github is much much more than version control. It's also bug tracking, feature tracking, discussions, web hosting, wiki, release management, etc.
Not enough for a snow day (unless you are doing it wrong.) Hell, if you are doing it right, you can still be productive during a days-long outage.
When all that goes down, you can still write code, but you can't communicate with the other devs anymore.
Email, IM, skype. I mean, Jebuz on a pony, you make it sound like there a civilization collapse, and that we start using smoke signals and runners carrying clay tables filled with cuneiform.
You don't give them any source code. You create interfaces (in the Object Oriented Programming sense) and "dummy" implementation version of what your executables do. You provide these to the subcontractors.
This way, they can work on the new source code remotely, without accessing the existing proprietary stuff.
That's what API's are partially for. There is a shit-load of behavior that cannot be captured with APIs alone. APIs are necessary, but not sufficient. If you think APIs will insulate you from the issues being discussed here, you are in for a nasty surprise.
If someone is willing to ignore your NDA, then they're also willing to walk off with a copy of the code.
This is assuming the source code is actually worth something to someone else. Most companies have a wildly inflated idea of what their code would be worth to a competitor. In general, your competitors have no interest in seeing your crappy code, and are too busy with their own problems.
I once consulted for a company that decided to "open source" some of their code. There were objections that they were giving away their "crown jewels", but they went ahead and did it. A year later, they had this many downloads of the code: 0.
Be that as it may, it would be irresponsible for a company to be careless to protect its intellectual property (even if it is shitty.) Also, sometimes the code might be shitty, but *what it does* is what is important. Without disclosing, I've seen some truly crappy code that yet are integral parts of systems delivering hundred of millions in value.
The potential value of a system is not just on how it is constructed, but in the services that it can render. And like any business, systems might operate on the red for years before turning a profit. So until you know for sure, you gotta protect your jewels, even if your "jewels" are nothing but a pair of dried out raisins:P
To add to what I said, thinks BSD jails or Solaris "zones". If you see the reasoning behind any of these two, you get the reasoning behind Docker. Again, it all depends on the work requirements.
Could we make things a bit more complicated? Virtualization I understand. I don't understand the need for Docker.
Docker allows you to "packetize" your applications into their own secure containers in a standard format, with standard lifecycles. It makes it easier to distribute and deploy systems. And in cases when you want to provision environments, it gives you greater granularity.
In terms of provisioning virtualized environments (say a server that collocates systems A, B and C), without something like Docker, you have to provision an entire system for each combination/version of A, B, and C. That creates a burden in terms of backups, snapshots and storage.
With Docker, all you need is to virtualize the base system, the host, onto which you can deploy the Docker image of the systems in question.
It is just another layer that will break.
Every layer has a potential to brake. And by the same token, systems with less layers than they need will also break. How much layers you need, that is specific to the work at hand.
Maybe I am just getting old, but this seems very complicated and prone to breakage with all the layers.
One could argue with separating authentication from authorization (instead of cobbling them together into a single "security" layer). And why separate security from application. Let's couple the shit out of them.
Again, it all depends on the work requirements at hand.
Slashdot Mirror
They way I figure it, using drag and drop to add code structures is just an eye-candied version of autocomplete in a text-based IDE, and it goes back to the original post: If they don't know what they are doing, they will suck at coding.
Does it matter at this stage? These tools are typically geared to kids younger than 3-4 grade (hell, the prime target would be 1st and 2nd graders.) To me, what matters at this stage is to ignite a sense of wonder and a sense that problems can be broken down into discrete, repeatable blocks: look, I can move the character 6 steps front, then 6 steps back, and making him say hello! Repeatedly, like forever! I wonder if I can make it do something else.
That's what these tools are for.
It shouldn't matter how the code itself is created.
As a professional software engineer, I disagree with that. It absolutely matters how the code was created. If you cannot create the code yourself from scratch and must rely instead upon templates, wizards and drag till you drop GUIs, you're doing it wrong.
Yes and No.
The No part: Most of us know conceptually how a compiler tool chain works, but I doubt most of us can bang the fundamental machine code that a compiler/linker generates. The tool chain is in essence nothing more than a very smart template and wizard system.
Similarly, I know how I could write a HTML templating system (say, something like JSP or Velocity), but I doubt I could get something that works like those in a reasonable amount of time.
Reliance of templates and wizards and drag-n-drop magic =/= not knowing how they work.
That is, a person needs to know the powers and limitations of those tools, and then leverage them appropriately for the right problems.
The Yes part: Too many people rely on wizards without knowing how to use them appropriately. Then they don't know how to untangle themselves from the monstrosities they create.
With that said, we must separate the issue of 1) people not knowing how to use high-level tooling from 2) the value of such tooling when applied correctly to the appropriate problems.
In this very specific case, we are talking about graphical tools to introduce kids to programming. Not adults, not full-fledged software engineers, but kids. Somewhere along the line we have completely lost perspective of what truly matters in this particular context. We already have far too many people like that in this profession and the public wonders why their software is chock full of silly bugs, runs slow and reliability is poor. Using tools may be alright, if you know what you're doing, but if you could not work without them or don't understand what they're doing for you under the hood, you're just asking for trouble. When push comes to shove, there is no substitute for the text editor and the command line. Giving kids a false sense of achievement was a disaster for my generation with the whole "self esteem" fad and "everyone gets a trophy for participating". Unfortunately for our kids, the liberal dingbats who inhabit our public education system seem to have learned nothing from the 1980s and remain intent upon repeating the failures of the past. People like me succeeded in spite of public education, not because of it. Educators and their Code.org friends would do well to remember that.
It is insightful, perhaps you didn't understand the language it was written in?
In English it says, "What are they talking about, they just spewed a bunch of words without enough context to even identify which jargon set is being used. And the key word is a relatively new product/project, whose name is repeated umpteen times like it was written by a marketing droid, but is never explained even in context of the other jargon words."
Also, you just signed up yesterday, I can tell by your user id. You don't get to pine for my golden days of yesteryear, those are mine. Get your own, order them now and you can have them in a couple decades when you forget what it was really like.
LOL. Da'fuk? I have a submission on 2011, so obviously is not yesterday. Plus I had another account that goes back to 1998. But whatever, a post is worth by its content, not but the longevity of the account (and the fact that you use the later speaks more about you than about me.)
But Drag and Drop Doesn't = Coding, argues Yue.
So much for BPMN, where you can actually create a significant amount of useful function just by doing that.
The thing about Mr. Yue's comments, however, is that he is completely missing the mission of all those drag-n-droppey efforts is not to equate cute little draggable blocks and call it coding. It is to get kids interesting.
I mean, for fucks' sake, we don't call kindergarten wooden counting blocks differential equations, do we?
"Unlimited" does have a very specific meaning, and in this case it means unlimited photos, not unlimited steganography.
Exactly. The fact we have to spell that shit out is scary. Bring back the dinosaurs, humanity has failed!
What are they talking about, and why do I care about the size of the container Levi's ships my Docker khakis in?
I find it scary that this post above was actually mod'ed insightful. Slashdot, wtf happened to you?
tiny tinie
Corporations are not people and should not ever be offended. Being rude to a company should not affect the way the company does business or whom it does business with. It is just Musk being a douche, because he's becoming arrogant.
When you are rude to a company, you are rude to the employees. Good managers and owners cut off shitty customers from the start to avoid that kind of shit from happening (which can have terrible consequences down the road - I have witnessed this. The customer is not always right.).
I am not saying this is exactly what happened in the story. I'm simply giving you a counter-argument to the above statement of yours.
Some of the "warning" -Wall checks and calls out are asinine. There not worth the time to "fix" just to make the compiler happy.
I cannot remember a concrete, very specific case from ages past where this was true. But in general, and after seeing a ton of code, if you start from the beginning with -Wall -Werror and don't let that shit go, it goes a long way towards maintainability.
Additionally, the moment you let that discipline go, things begin to go to shit. And before you know it, you have your compilation logs fulled with warnings that you cannot turn off because of the off change one of them might be relevant, and no way to go back and clean that shit up because the technical debt is too huge.
I hate working with projects were -Wall -Werror is not the norm for the bulk of source code. In the general case, warnings are latent errors and you might as well squash them without mercy before the creep out of your control.
GNU Hurd Begins Supporting Sound
Yeah, but.... can it draw sounds?
Did a libtard SJW submit this story? They really hate free speech.
Free speech becomes hate speech. Speaking your mind becomes frowned on.
And this is bad because...? Welcome to life dude. Yes, speaking your mind becomes frowned on. Does that stops you from speaking your mind as a matter of principle? You need to really live in a state of repression to understand how precious it is to speak your mind, even if everyone else frowns on you.
Why Does Twitter Refuse To Shut Down Donald Trump?
I hate Trump, but I would never accept as appropriate for the Internet and the Media (and twitter is a de-facto part of the Media) to shut him down. Who the fuck could possibly ask for that?
Freedom of speech works both ways, and to uphold it demands from us to listen to that which is objectionable (and to deal with it with counter-arguments, not censorship.)
I understand that, in principle, Freedom of Speech does not forbid private media to censor free thought, unlike public media and government. But it is disenginuous to demand Twitter to censor Trump? Why? Because he is a misogynistic man-child who spouts vile racial shit to arouse those on the edge of nationalistic fervor?
Fuck that. Fuck your sensitivities. You don't censor that shit. You confront it heads on in the rhetoric arena. Let's face it, between 1/4 and 1/3 of the population believe the shit he says (and loves him because of the shit he says). Trumps speaks to them.
Do you think censorship is going to make that go away? No. In fact, it will make him a martyr to those idiots who go happy-bug-eye for him. You gotta let that shit come in the open. Let that stupidity be in the open for the world to see. Then attack it with counter-arguments, and with behavior as counter-examples.
To pussy up behind a wall of censorship that prevents to see the ugly realities of 'Murika, how the hell does that help?
So does every other language...what's your point?
He is having problems with his homework. You know, OP is just suffering from "little rebel without a cause with zero exposure outside the classroom" syndrome.
A proper scrum master would never have such problems.
Wait, scrum masters do source control administration? :)
I've been bitten by more BitBucket outages than I've seen GitHub disruptions :p
Which is why you should have code bases in both (pick your primary in either, and keep the other one as a hot backup.) If a system is worth going through the trouble of constant availability and reliability, this is the only way to go.
As a user of source control in general- if you need an admin for it, you're doing it wrong.
No. You are doing it wrong (inexcusable) , or you are not working on a large scale system (understandable.). As your systems and teams grow in size and complexity, you need gatekeepers. And you need people in charge of doing sysadmin work, backups and stuff, including maintaining and backing up your main repositories.
Beyond a certain team size, it is not cost effective to have developers managing those resources. You want them to develop. Yes, you might have a few developers part-timing on those roles (or even better, have a close relationship with IT support, ala DevOps.)
But you need specialization. This specially true when your organization has source control platforms that cater not only to your projects, but other projects within the organization. Then you need centralized administration.
No ability to use the automated build system that pulls updates or source code exports from git tags at github. No configuration publication or web content updates with github based branches. Sharing code between repositories locally is still feasible, but loses the insurance that the code submitted to production has been submitted somewhere accessible to other programmers.
Email the deltas if you have to. And if you are in a real emergency, you can clone and upload your local copy into bitbucket.
We had a situation like that where we lost our infrastructure a couple of months ago. We couldn't code, we couldn't build, we couldn't do integration testing. Total blackout. Rather than waiting for Ops to bring everything back online, we stopped coding and migrated everything we needed on a different system. We lost a lot of history, but we were back on track.
It was either that on pick our noses during a down time twice as long.
Shit happens. If a team cannot find ways to work around it and make progress, however shaky it might be, I question their abilities. The fallacies of distributed systems applies to people, too.
Don't you have pull requests that need your attention?
Maybe there are pull requests that required attention before the outage, and that are in the works. Maybe you cannot commit, but you have more test cases to refine, more documentation to write. Oh yes, the stuff you have on your backlog, you can work on that too while you are at it. And if you really have to have someone get your changes (because shit, they are urgent), you can pull a worst-case scenario and e-mail your changed files to the appropriate recipient (because I'm certain your e-mail is not dependent on git.)
There is always work to be done. Unless you are complete unorganized and are unable to work independently, without peerage and supervision.
I refactored some of your code to use more inclusive variable names and expect you to respond by January 29th, otherwise we will demand you step down from your role as project maintainer.
CAPTCisHCisC: brothers
Because doubling down on the bat shit crazy makes your argument all the more plausible.
Github is much much more than version control. It's also bug tracking, feature tracking, discussions, web hosting, wiki, release management, etc.
Not enough for a snow day (unless you are doing it wrong.) Hell, if you are doing it right, you can still be productive during a days-long outage.
When all that goes down, you can still write code, but you can't communicate with the other devs anymore.
Email, IM, skype. I mean, Jebuz on a pony, you make it sound like there a civilization collapse, and that we start using smoke signals and runners carrying clay tables filled with cuneiform.
You don't give them any source code. You create interfaces (in the Object Oriented Programming sense) and "dummy" implementation version of what your executables do. You provide these to the subcontractors.
This way, they can work on the new source code remotely, without accessing the existing proprietary stuff.
That's what API's are partially for. There is a shit-load of behavior that cannot be captured with APIs alone. APIs are necessary, but not sufficient. If you think APIs will insulate you from the issues being discussed here, you are in for a nasty surprise.
To make space, CERN engineers have set out to identify and remove the old, unused cables. All 9,000 of them
And that, children, is what happens when decommissioning is not a concrete, well-thought off, first class phase in a system's life cycle.
If someone is willing to ignore your NDA, then they're also willing to walk off with a copy of the code.
This is assuming the source code is actually worth something to someone else. Most companies have a wildly inflated idea of what their code would be worth to a competitor. In general, your competitors have no interest in seeing your crappy code, and are too busy with their own problems.
I once consulted for a company that decided to "open source" some of their code. There were objections that they were giving away their "crown jewels", but they went ahead and did it. A year later, they had this many downloads of the code: 0.
Be that as it may, it would be irresponsible for a company to be careless to protect its intellectual property (even if it is shitty.) Also, sometimes the code might be shitty, but *what it does* is what is important. Without disclosing, I've seen some truly crappy code that yet are integral parts of systems delivering hundred of millions in value.
The potential value of a system is not just on how it is constructed, but in the services that it can render. And like any business, systems might operate on the red for years before turning a profit. So until you know for sure, you gotta protect your jewels, even if your "jewels" are nothing but a pair of dried out raisins :P
To add to what I said, thinks BSD jails or Solaris "zones". If you see the reasoning behind any of these two, you get the reasoning behind Docker. Again, it all depends on the work requirements.
Docker actually makes things simpler! Since you understand virtualization, then think of docker as lightweight virtualization.
how is adding stuff on top of LXC making things simpler?
i followed docker from its inception and to me and my colleagues, they are the microsoft of os-level virtualisation.
What's complicated about Docker?
Could we make things a bit more complicated? Virtualization I understand. I don't understand the need for Docker.
Docker allows you to "packetize" your applications into their own secure containers in a standard format, with standard lifecycles. It makes it easier to distribute and deploy systems. And in cases when you want to provision environments, it gives you greater granularity.
In terms of provisioning virtualized environments (say a server that collocates systems A, B and C), without something like Docker, you have to provision an entire system for each combination/version of A, B, and C. That creates a burden in terms of backups, snapshots and storage.
With Docker, all you need is to virtualize the base system, the host, onto which you can deploy the Docker image of the systems in question.
It is just another layer that will break.
Every layer has a potential to brake. And by the same token, systems with less layers than they need will also break. How much layers you need, that is specific to the work at hand.
Maybe I am just getting old, but this seems very complicated and prone to breakage with all the layers.
One could argue with separating authentication from authorization (instead of cobbling them together into a single "security" layer). And why separate security from application. Let's couple the shit out of them.
Again, it all depends on the work requirements at hand.