|
I’m not sure when coding started to replace programming as the term for what we do, but I suspect it was around the time when non-technical executives began to think of custom software as a commodity, when the perception emerged that you could get quality software development at bargain-basement prices. "That which we call a rose, by any other name would smell as sweet."
|
|
|
|
|
Kent Sharkey wrote: "That which we call a rose, by any other name would smell as sweet."
But no one will buy...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Sadly, programming is not yet a profession. Robert C Martin (Uncle Bob) has argued for progression in this direction a few times (e.g. Clean Coder Blog) - particularly arguing that we should really get our act together before external agents force it on us (probably badly, as governments rarely seem to do a good act of regulation nowadays).
At some stage, there will be a real disaster - financial or, FSM forbid, involving large loss of human life, that turns out to be the blame of shoddy software. At that stage it will be too late and regulation will be forced from above, probably badly.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Agile certifications aim to provide a meaningful way to benchmark software development skills and process and/or product management. But are they really meaningless credentials that provide no value? As much as other certifications
|
|
|
|
|
The funny thing about agile certifications is that although my CSM certification expired in 2013 (and is CLEARLY listed on my resume), I get phone calls from recruiters asking for a certified CSM.
Certifications are pretty much useless with exceptions in security and some IT shops. Otherwise they're pretty much only useful as low grade toilet paper.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."
-- Marcus Brigstocke, British Comedian
|
|
|
|
|
It highly depends on the quality of the paper... 
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
They mean a lot, and are enormously valuable...
... to the people who get paid to give out such certifications.
Think about it. Without certifications, where would the certification industry be today?
|
|
|
|
|
|
Prestigious investment bank predicts an $80 billion market by 2025. If so: invest in anti-nausea pills
|
|
|
|
|
At last - we can put banner adverts on the sky, the sea and the setting sun. Oh this VR will be such fun!
(Douglas Adams' anti-peril glasses are probably on the plans too)
|
|
|
|
|
C++ provides two calling syntaxes, x.f(y) and f(x,y). This has bothered me for a long time. A call about calls, from Bjarne
|
|
|
|
|
|
Not really relevant in this case.
First, there remains only one C++ Standard.
Second, they are not adding a new type of call, simply saying that two existing types become closer to equivalent.
It is one of those rare cases when they are actually simplifying the language. These are so uncommon they should be a cause for celebration.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
 Quote: To my surprise, many people came out strongly against x.f(y) finding f(x,y) – even if member functions were preferred over free-standing functions by the lookup rules. I received email accusing me of “selling out to the OO crowd” and people whose experience and opinion I respect insisted that x.f(y) finding f(x,y) would seriously compromise their ability to design stable interfaces. I think those fears are greatly exaggerated, but I could be wrong. Also, I prefer the dot syntax in some cases; for example, I find x.f(y).g(z) more readable than g(f(x,y),z). However, there was no chance of acceptance of a proposal that included x.f(y) finding f(x,y). Maybe modules will eventually help here. Furthermore, David Vandevoorde pointed out that because of the two-phase lookup rules having x.f(y) find f(x,y) would complicate the task for compiler writers and possibly be expensive in compile time.
So, we are left with a simple proposal to allow f(x,y) to find x.f(y) where f(x,y) wouldn’t work today.
Could someone explain why allowing f(x,y) to find x.f(y) is apparently so much easier than allowing x.f(y) to find f(x,y)?
Also, while not explicitly stated, the article's implying that f(x,y) to x.f(y) is going to be less bad for API maintainers. I'm not really seeing why one version would be less of a potential problem than the other. Also, while there probably are legacy APIs where the two aren't the same - preventing the simplest implementation - I can't think of a reason for doing so that isn't a cluster elephant. That being the case, any argument on the line of "mapping one to the other would limit my future options by preventing me from having both and making them work differently" sounds like "I want to be able to do something stupid". Again, am I missing something here?
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
|
|
|
|
|
|
|
Ooops. I even did a search of the forums for "apple" and "ios" before posting.
|
|
|
|
|
The real question to ask, though, is why this figure is so important to Microsoft. Misleading market share numbers? I thought they were always carefully caudally extracted
Or pulled from a popo with precision?
|
|
|
|
|
Kotlin is a pragmatic programming language for JVM and Android that combines OO and functional features and is focused on interoperability, safety, clarity and tooling support. There you go: I know you wanted a new language to learn
|
|
|
|
|
XAML Behaviors have long been a frustrating part of WPF/Silverlight development. Though incredibly useful, the libraries were distributed and maintained in a strange fashion. That problem has finally been resolved with the announcement that XAML Behaviors would be open sourced and a matching NuGet package created. Which probably means they're stopping active development
|
|
|
|
|
Kent Sharkey wrote: Which probably means they're stopping active development
Or they need the community to finally solve all those bugs?
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
We gravitate toward familiar tech because it's the comfortable, low-risk route. "Any one who thinks is an agnostic about something, otherwise he must believe that he is possessed of all knowledge."
|
|
|
|
|
In an ideal world, it would be nice to be capable of developing on every platform/language/technology. In practice, this should be tempered by the skill set of developers available. There's no point adopting a technology without the skills to use it.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
So - an uncomfortable high risk route is beneficial because...?
(I agree we should try to be tech-agnostic using things like repositories, micro-services and interfaces etc. but it is not the case that "language agnostic" is a component of "technology agnostic" and it is not always the case that newer means better)
|
|
|
|
|
But of course! After all all we do is for fun and learning and passing the time...It has nothing to do with earning money, deploying applications or all those real-word bullocks...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
