I wish I knew these things when I learned Python | Bugra Akyildiz:
"I sometimes found myself asking myself how I cannot know simpler way of doing “this” thing in Python 3. When I seek solution, I of course find much more elegant, efficient and more bug-free code parts over time. In total(not just this post), the total sum of “those” things were far more than I expect/admit, but here is the first crop of features that was not obvious to me and learned later as I sought more efficient/simple/maintainable code."
'via Blog this'
Wednesday, 3 August 2016
Five Ways to Not Mess Up Microservices in Production
Five Ways to Not Mess Up Microservices in Production: "Ealier this month Takipi's Alex Zhitnitsky wrote about five ways not to mess up microservices in production (OK, "mess" wasn't exactly the word he used!). He builds on the output of the panel discussion we reported on a few months back as well as their own users, examining the top production problems with microservices and how to solve them. The emphasis, as we will see, is on distributed debugging and approaches which can help to make this a tractable effort."
'via Blog this'
'via Blog this'
Destroy All Ifs — A Perspective from Functional Programming – John A De Goes
Destroy All Ifs — A Perspective from Functional Programming – John A De Goes:
"I’ve long argued that, despite all its flaws, one of the great things about functional programming is its intrinsic inversion of control.
In an impure imperative language, if you call some function void doX(State *state), the function can do anything it wants. It can modify state (both passed in and global), it can delete files, it can read from the network, and it can even launch nukes!
In a pure functional language, however, if you call some function doX :: State -> IO (), then at most it’s going to return a value. It can’t modify what you pass it, and if you like, you can ignore the value returned by the function, in which case calling the function has no effect (aside from sucking up a little CPU and RAM).
Now granted, IO in Haskell is not a strong example of an abstraction that has superior reasoning properties, but the fundamental principle is sound: in pure functional programming languages, the control is inverted to the caller.
Thus, as you’re looking at the code, you have a clearer sense of what the functions you are calling can do, without having to unearth their foundations.
I think this generalizes to the following principle:
Code that inverts control to the caller is generally easier to understand.
(I actually think this is a specialization of an even deeper principle — that code which destroys information is generally harder to reason about than code which does not.)
Viewed from this angle, you can see that if we embed conditionals deep into functions, and we call those functions, we have lost a certain amount of control: we feed in inputs, but they are combined in arbitrary and unknown ways to arrive at a decision (which code path to take) that has humongous ramifications on how the program behaves.
It’s no wonder that conditionals (and with them, booleans) are so widely despised!
In an object-oriented programming language, it’s generally considered a good practice to replace conditionals with polymorphism.
In a similar fashion, in functional programming, it’s often considered good practice to replace boolean values with algebraic data types."
'via Blog this'
"I’ve long argued that, despite all its flaws, one of the great things about functional programming is its intrinsic inversion of control.
In an impure imperative language, if you call some function void doX(State *state), the function can do anything it wants. It can modify state (both passed in and global), it can delete files, it can read from the network, and it can even launch nukes!
In a pure functional language, however, if you call some function doX :: State -> IO (), then at most it’s going to return a value. It can’t modify what you pass it, and if you like, you can ignore the value returned by the function, in which case calling the function has no effect (aside from sucking up a little CPU and RAM).
Now granted, IO in Haskell is not a strong example of an abstraction that has superior reasoning properties, but the fundamental principle is sound: in pure functional programming languages, the control is inverted to the caller.
Thus, as you’re looking at the code, you have a clearer sense of what the functions you are calling can do, without having to unearth their foundations.
I think this generalizes to the following principle:
Code that inverts control to the caller is generally easier to understand.
(I actually think this is a specialization of an even deeper principle — that code which destroys information is generally harder to reason about than code which does not.)
Viewed from this angle, you can see that if we embed conditionals deep into functions, and we call those functions, we have lost a certain amount of control: we feed in inputs, but they are combined in arbitrary and unknown ways to arrive at a decision (which code path to take) that has humongous ramifications on how the program behaves.
It’s no wonder that conditionals (and with them, booleans) are so widely despised!
In an object-oriented programming language, it’s generally considered a good practice to replace conditionals with polymorphism.
In a similar fashion, in functional programming, it’s often considered good practice to replace boolean values with algebraic data types."
'via Blog this'
What kubernetes and cloud9 tell us about the new industry – anyone but Amazon – James Governor's Monkchips
What kubernetes and cloud9 tell us about the new industry – anyone but amazon – James Governor's Monkchips: "We used to talk about the Anyone but Microsoft club. Arguably the triumph of open source in the enterprise was a result of the same driver. Linux was a means to avoid Microsoft operating system domination. Vendors would push an alternative, and customers would support it partly as means to hedge their bets against too much domination by a single provider.
Today the dominant vendor scaring tech providers is clearly Amazon Web Services.
One facet of today’s Anyone but Amazon coalition is OpenStack. AWS dominance led pretty much every other major tech vendor, no matter how competitive to converge on OpenStack, as an open hedge.
When pondering the implications of Microsoft’s hiring of Brendan Burns the other day, it struck me another coalition is forming, changing the fault lines of the industry. Burns is one of the founders of the Kubernetes container cluster manager project. He was at Google but just took a job as product lead for the Azure Resource Manager. He has already publicly declared he will continue to work on Kubernetes. Kubernetes has also been enthusiastically adopted by Red Hat, through it’s OpenShift platform.
So now Microsoft, Red Hat, and Google Cloud Platform are all now aligned around Kubernetes. While at first glance this new alliance of strange bedfellows might seem to be a response to the rise of Docker and the Docker Pattern – and indeed there is no doubt the enthusiastic growth in Kubernetes is partly driven by concern that Docker will own too much real estate of the new infrastructure world I believe the overarching threat is Amazon.
As Stephen has explained – the biggest competitor to open source is Amazon. There is no doubt that Amazon EC2 Container Services is going to gain wide traction. Amazon can afford to be magnanimous about Docker’s rise in a way other vendors can’t. Docker is an implementation detail rather than a potential existential threat to AWS.
This week another shoe dropped, when Amazon announced it is acquiring Cloud9, the online IDE startup. Cloud9 created Ace, which also powers the GitHub editor."
'via Blog this'
Today the dominant vendor scaring tech providers is clearly Amazon Web Services.
One facet of today’s Anyone but Amazon coalition is OpenStack. AWS dominance led pretty much every other major tech vendor, no matter how competitive to converge on OpenStack, as an open hedge.
When pondering the implications of Microsoft’s hiring of Brendan Burns the other day, it struck me another coalition is forming, changing the fault lines of the industry. Burns is one of the founders of the Kubernetes container cluster manager project. He was at Google but just took a job as product lead for the Azure Resource Manager. He has already publicly declared he will continue to work on Kubernetes. Kubernetes has also been enthusiastically adopted by Red Hat, through it’s OpenShift platform.
So now Microsoft, Red Hat, and Google Cloud Platform are all now aligned around Kubernetes. While at first glance this new alliance of strange bedfellows might seem to be a response to the rise of Docker and the Docker Pattern – and indeed there is no doubt the enthusiastic growth in Kubernetes is partly driven by concern that Docker will own too much real estate of the new infrastructure world I believe the overarching threat is Amazon.
As Stephen has explained – the biggest competitor to open source is Amazon. There is no doubt that Amazon EC2 Container Services is going to gain wide traction. Amazon can afford to be magnanimous about Docker’s rise in a way other vendors can’t. Docker is an implementation detail rather than a potential existential threat to AWS.
This week another shoe dropped, when Amazon announced it is acquiring Cloud9, the online IDE startup. Cloud9 created Ace, which also powers the GitHub editor."
'via Blog this'
Microsoft REST API Guidelines
api-guidelines/Guidelines.md at master · Microsoft/api-guidelines · GitHub:
"The Microsoft REST API Guidelines, as a design principle, encourages application developers to have resources accessible to them via a RESTful HTTP interface. To provide the smoothest possible experience for developers on platforms following the Microsoft REST API Guidelines, REST APIs SHOULD follow consistent design guidelines to make using them easy and intuitive.
This document establishes the guidelines Microsoft REST APIs SHOULD follow so RESTful interfaces are developed consistently."
'via Blog this'
"The Microsoft REST API Guidelines, as a design principle, encourages application developers to have resources accessible to them via a RESTful HTTP interface. To provide the smoothest possible experience for developers on platforms following the Microsoft REST API Guidelines, REST APIs SHOULD follow consistent design guidelines to make using them easy and intuitive.
This document establishes the guidelines Microsoft REST APIs SHOULD follow so RESTful interfaces are developed consistently."
'via Blog this'
Tuesday, 2 August 2016
Why Cisco's data center strategy depends on simplifying storage - TechRepublic
Why Cisco's data center strategy depends on simplifying storage - TechRepublic: "Cisco recently announced a MapR-based SAP HANA appliance. MapR is described as a converged data platform, and Cisco is leveraging the platform to create a dedicated x86-based SAN for the SAP HANA persistent layer.
A major difference between HyperFlex and the MapR-based SAP HANA appliance is the storage and compute nodes are not mixed. MapR creates a dedicated layer for storage separate from the application servers.
Cisco's storage strategy has a complicated history. The current set of technologies is focused on specific verticals. However, Cisco needs to place some consistency behind a single strategy before customers buy wholesale into a Cisco-only data center strategy."
'via Blog this'
A major difference between HyperFlex and the MapR-based SAP HANA appliance is the storage and compute nodes are not mixed. MapR creates a dedicated layer for storage separate from the application servers.
Cisco's storage strategy has a complicated history. The current set of technologies is focused on specific verticals. However, Cisco needs to place some consistency behind a single strategy before customers buy wholesale into a Cisco-only data center strategy."
'via Blog this'
Adam Leventhal's blog » I Love Go; I Hate Go
Adam Leventhal's blog » I Love Go; I Hate Go: "I’m sure time will, as it tends to, bring pragmatism. I appreciate that Go does have strong opinions (it’s just hard to remember that when I disagree with them). Weak opinions are what turn languages into unreadable mishmashes of overlapping mechanism. My favorite example of this is Perl. My first real programming job was in Perl. I was the most avid reader teenage of the Perl llama and camel books.
Ask me about my chat with Larry Wall, Perl’s creator, if you see a beer in my hand. In an interview, Larry said, “In Perl 6, we decided it would be better to fix the language than fix the user”.
Contrast this with Go’s statement on assertions:
Go doesn’t provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting.
Perl wants to be whatever the user wants to be. The consumate pleaser. Go sees the user as flawed and the strictures of the language as the cure. It’s an authoritarian, steadfast in its ideals, yet too sensitive to find compromise (sound like anyone we all know?).
Despite my frustrations I really enjoy writing code in Go. It’s clean and supported by a great community and ecosystem."
'via Blog this'
Ask me about my chat with Larry Wall, Perl’s creator, if you see a beer in my hand. In an interview, Larry said, “In Perl 6, we decided it would be better to fix the language than fix the user”.
Contrast this with Go’s statement on assertions:
Go doesn’t provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting.
Perl wants to be whatever the user wants to be. The consumate pleaser. Go sees the user as flawed and the strictures of the language as the cure. It’s an authoritarian, steadfast in its ideals, yet too sensitive to find compromise (sound like anyone we all know?).
Despite my frustrations I really enjoy writing code in Go. It’s clean and supported by a great community and ecosystem."
'via Blog this'
Subscribe to:
Posts (Atom)