|
Actually I can't agree with any of that. Command lines are super useful and anyone who calls himself "programmer" but refuses to use the command line is either ignorant or not a (good, or even mediocre) programmer. You can't do proper automation without a command line. Hence the command line gives you productivity.
|
|
|
|
|
Florian Rappl wrote: is either ignorant or not a (good, or even mediocre) programmer.
Well, I guess I'm ignorant and a piss poor programmer.
I absolutely refuse to use the command line except where I'm forced to, for example when backing up a Postgres database on Ubuntu. The only time I use the command line with Git is to clone a repo. Etc...
Florian Rappl wrote: You can't do proper automation without a command line.
Really. I do all sorts of automation without futzing around with the command line.
Marc
|
|
|
|
|
How can you do that?
Just to be clear: Microsoft thought for a while VBA is the way to do automation. Then they realized it sucks and gives you no flexibility at all. At that point Snover came to rescue the day and created the PowerShell. Now that enables you to do automation. And since then EVERYTHING is API driven first. Before that managing Windows servers (multiple) has been a nightmare. Now if you can teach me how you can do automation without a proper API that runs on the command line I would be delighted. I have no idea how that could work and be as general, agile and open as a command line.
|
|
|
|
|
Maybe I don't understand what you mean by automation. For me, for example, I wrote a little applet that watches for file updates across a bunch of different folders and copies the updated files to a centralized install folder, which made it a lot easier to package up for the client. Similarly, automatically FTP'ing files up to my web server's test folders when I make changes to a web app, so the client can test out new features, without me having to go through the whole ridiculous "publish" process from Visual Studio. I imagine these things could all be done with a CL too though.
Marc
|
|
|
|
|
What you mention is certainly one part of automation - again everything API driven. What I was after is the automation on the system configuration level. Of course you can write scripts for everything. But a script is - after all - only using commands that can be executed in the command line or some other shell environment.
In general I think of automation as repeating certain actions, maybe with some variation that may depend on input parameters. The automation you described fits, but it is only possible because either there is some existing API or you use the command line arguments (!) of a program.
If the only way to configure a Windows Server would be over a GUI, then configuring a whole bunch of them is tedious and error-prone. But if you can just go and execute a simple script, which takes care of everything, then the process is much easier to control, execute and test.
|
|
|
|
|
Java is 20. Where does it go from here? "That is not dead which can eternal lie"
|
|
|
|
|
Researchers are finding no obvious signs of life after digging through thousands of galaxy images in search of advanced civilizations. That's because they were "A long time ago"
|
|
|
|
|
They might try looking out the window.
|
|
|
|
|
PIEBALDconsult wrote: They might try looking out the window.
I still don't see any signs of advanced civilization.
Marc
|
|
|
|
|
...or intelligent life at least.
|
|
|
|
|
100K is what like .0002% of the sky? Keep looking guys, you're just getting started.
Hold my drink and watch this.
|
|
|
|
|
A galaxy is too large to discard and more so being as far as they are from one another. Intergalactic space is inconceivably immense. Perhaps they meant 100,000 star systems.
|
|
|
|
|
Actually, they're looking "a long time ago". Life could have evolved in the time it takes light to cover the distances involved in some cases.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Technical responses hurt my joke organ, even when completely accurate.
TTFN - Kent
|
|
|
|
|
I wonder what will happen if they DO find something
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Now, a free extension for Visual Studio gives C# and XAML developers a way to code HTML5 apps from the comfort of Microsoft’s IDE. "Silverlight for HTML5"? So, it will get cancelled after people start using it?
|
|
|
|
|
Kent Sharkey wrote: "Silverlight for HTML5"? So, it will get cancelled after people start using it?
I don't care.
that allows developers to build client-only rich Web or ‘single-page’ apps completely in C# and XAML, without having to write any JavaScript, HTML, or CSS.
I want (even though I despise XAML).
Marc
|
|
|
|
|
Recent events suggest that pushing enhanced privacy- and security wares brings risks with few rewards. “Come at me Bro”
|
|
|
|
|
...and yet OpenBSD has managed to boldly claim "Only 2 remote holes in the default install in a heck of a long time" for a heck of a long time.
It takes a proactive approach to security to get there, but it is possible. It always baffles me why OpenBSD is not more popular for servers and applications where security really matters.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: It always baffles me why OpenBSD is not more popular for servers and applications where security really matters.
The article itself covers that:
Quote: "Here's the problem," explains John Dickson, a Principal at the Denim Group. "You have to be as good as the other, less secure tool and you have to be secure. That's a bridge too far for many products."
Linux has had a major advantage in terms of easy buttonsconsoles over the BSDs that make it easier to put to use for a long time.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I believe that developers should measure once, quickly, for a rough estimate, and then cut. Save even more time: don't bother measuring
|
|
|
|
|
Measure schmeasure; we have undo, version control, and future releases.
|
|
|
|
|
Just because software is malleable, doesn't mean there is zero cost to maintenance.
I believe we could learn a lot from industrial design, where a series of prototypes are frequently made and refined, but the final cut is designed to be durable and maintainable (depending on the project's constraints).
There are many types of software projects. Some require the entire thing to be correct on delivery (consider control systems for nuclear reactors, or cars). Others require continual changes (many web applications). The key is to choose an approach that matches the application.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: Just because software is malleable, doesn't mean there is zero cost to maintenance.
Yep. The one app I maintain's 3 biggest pain points for me are all things that were done due to severe time pressure (partly our underestimating complexity, partly the customer pushing a lot more scope creep/churn before the PM finally drew a line in the sand) that are too complex to fix short of a major update whose budget continues receding into the future. The biggest user painpoint is something that looks like it would be a simple change in the code; but involves breaking a major invariant in the existing platform that no one involved (I wasn't) remembers if was done because the CM lover wanted to Lock Down All The Things, or because it was the quickest way to mitigate a problem found in early testing. That makes its potential unintended consequences broad enough that unlike the dozens of minor hotfixes and tweaks that've been done since release, an update of an full rerun of the manual test plan to mitigate risks.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I had to read a lot of this article twice, to ensure that it was as full of bollocks as it seemed on the first read.
The writer obviously knows absolutely bugger-all about building, absolutely bugger-all about the meanings/origins/usage of English expressions, nothing about agile/waterfall, and probably bupkiss about program design, although it looks like he/she/it may have done a two-week course on it.
Back when I used to do editorial work, I'd have shredded this; I wouldn't have even sent it back.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|