|
I suppose you already found this excellent site: https://fsharpforfunandprofit.com/
It not only covers the language, but also many concepts.
I read big parts of it when I was commuting by train (in Belgium that gives you sometimes more time than you planned  )
|
|
|
|
|
Gaston Verelst wrote: I read big parts of it when I was commuting by train (in Belgium that gives you sometimes more time than you planned )
I hope you read the 'railway oriented programming' parts on the train...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
I did, it gave me a bitter-sweet taste
|
|
|
|
|
The two F# books I have (which seem pretty good) are Essential F# and Domain Modeling Made Functional, which is by the same gut (Scott Wlaschin) who's produced the F# for Fun and Profit website mentioned elsewhere.
As for the bits of jankiness where F# and .NET collide...well, when you friction weld a functional first language like OCaml with an OOP first VM as in .NET, you get some mess at the boundary...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
I wasn't aware F# was based on OCaml (never used it but heard about it). Looked up the syntax and yea, I definitely see the inspiration.
|
|
|
|
|
I was reading this great article[^] on CP and it got me thinking:
Isn't SDLC and Agile rather orthogonal, even in opposition with each other?
And I suppose DevOps is sort of one piece of both, but possibly also in conflict with both?
What do you think? Are these "cult-ologies" compatible with each other?
|
|
|
|
|
I suppose Agile is a series of Micro-SDLCs.
DevOps is a meaningless buzzword.
|
|
|
|
|
SDLC can be used as an overarching plan for the Agile development process, so long as you're willing to review both in light of new information and user needs. The fundamental weakness with SDLC is it doesn't handle requirements changes well. The fundamental weakness with Agile is the general lack of overall lifecycle thinking.
|
|
|
|
|
Yeah, we just went to a weird flavor of agile and I've been clearly told that there is nothing but user stories. There is no overall design. I don't see it as a good thing, but that's not my problem ... or apparently anyone else's.
|
|
|
|
|
I've never had a high opinion of any of the formal software methodologies or their promoters. They all whiffed strongly of efforts by management to transform software development into a turn-the-crank process.
My group has run into this quite a bit, since we are a software group embedded in an engineering/R&D organization managed by mechanical engineers. The M.E.'s seem to be very fond of highly-detailed procedures for managing hardware development. I can see where these things work for them, but they're rarely applicable to software.
At the moment we're fairly free of this nonsense. As long as we produce, they're leaving us alone.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: They all whiffed strongly of efforts by management to transform software development into a turn-the-crank process.
Actually, I think Agile is an attempt by techies to bluff management into thinking there's an easy way to do software development. And, unsurprisingly, management fell for it! It's been one of the most successful 'grifts' in IT.
DevOps is now picking up the baton and trying to bluff management into thinking we don't need an SDLC.
We'll soon be back to the days of hacking code on Production, with no spec! I remember them well - the 'good old days'! 
|
|
|
|
|
No question but that management fell for it.
|
|
|
|
|
I think it's more a case of their susceptibility to the wiles of the Agile pimps than the developers got away with anything.
Software Zen: delete this;
|
|
|
|
|
|
Gary Wheeler wrote: I think it's more a case of their susceptibility to the wiles of the Agile pimps than the developers got away with anything.
Ahhhh, the 'real' Agile Manifesto:
We value:
- Repeated mantras over proof of benefits.
- Certification over knowledge, experience and talent.
- Blind acceptance over a questioning mind.
|
|
|
|
|
Actually, it's a really tough problem to solve.
How do you run a project that is part Artistic (requiring creativity), and Scientific, testable, repeatable, and educates the stakeholders as to the importance of their interacting and being available to the tech team trying to solve their problems?
Also, how do you prevent "cave dwelling" coders from hiding in their caves, coming out with something they thrust on the users, based on what the users asked for?
Having been around the industry for decades, and dabbling in management (but was a strong coder). I can see both sides. Furthermore, how do you manage this, when the complexity is huge?
And how do you get consistent results?
I don't think it was a grift, I think it was an attempt to COMMUNICATE the situation. The reason?
Because we ended up developing our OWN version of XP as a natural approach to these problems. I found that Agile did a great job of codifying/naming the problems. But, we only used pair programming for training. We used code reviews over TDD (We limited testing code to class/libraries).
While I saw some benefit to refactoring and TDD (and how it forced you to think FIRST as a CONSUMER of the functions, then the creator, but we did that naturally)... I could not justify the extra time/energy on all the test code. Leaning on code reviews was correct for us.
Finally, we PUSHED the concepts of "Points of Contact" with business, and the REQUIREMENT that they be available, and that they be allowed to make decisions (oh the pushback. They wanted Jane to answer our questions, but not be able to decide without 5 meetings on every decisions, in case she had it wrong).
I feel Agile helped the business people understand. You cannot withhold required information/decisions and demand we KEEP our deadlines!
It's tough. There are a lot of decisions. There are a ton of impacts, and a lot of risks. Besides that, the developers were usually expensive resources to tie up.
I can't blame anyone for working towards making it better than "Tell us what you want, and we will get back to you when we are done!"... LOL
|
|
|
|
|
I find that not one methodology fits for all needs, hence the need for various. SDLC, Agile, SCRUM, etc... depending on upper management and what they "understand" as being the methodology that will save them money is what they will implement and use/force down to us pawns.
In my humble opinion, albeit all have their benefits, I think that the system chosen should be flexible to accommodate what you are managing. Production line manufacturing, down to simple app design for the latest in-style/market hype. Some may like agile boards to see where the stage of development is, yet others like Gantt charts, while still others like simple list of tasks completion and percentages with charts. For now, management will decide which we follow.
This gives me an idea for an app.... 
|
|
|
|
|
5teveH wrote: I think Agile is an attempt by techies to bluff management into thinking there's an easy way to do software development. And, unsurprisingly, management fell for it! It's been one of the most successful 'grifts' in IT.
DevOps is now picking up the baton and trying to bluff management into thinking we don't need an SDLC.
That's the best definition of Agile and DevOps I've ever read! 
|
|
|
|
|
Is a lighthouse crossfit for moths?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
As long as you have a big enough pupa scooper.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
It attracts all sorts!
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
Bitly is a cloud service, with an automated API that you can use software to automatically create shortened links to stuff. The rocket scientists who invented it apparently never heard of spam bots before, so now the entire service is predictably overrun with spammers.
I've had to go to online communities I haunt and have them add the links to their spam filters. They are almost never legitimate.
Real programmers use butterflies
|
|
|
|
|
Rule 34.a -- if it exists, there is spam of it.
|
|
|
|
|
Link shorteners like bit.ly are pure evil.
Given that you're going to click on a link, not type it in, they serve no useful purpose.
They only serve to disguise malware of all sorts.
I never follow shortened links.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
It's important to me to carve a poem into the hide of time each 13-lunation cycle ... perhaps, a homeopathic remedy for suicidal ideation.
Often the poem is a long-winded, excessively metaphysical, collage of recursive obscurities 
This year's screed emerged in haiku-form:
time was a metal,
then a slurry, then liquid:
now, it's laughing gas
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
