Sound off!
I write the code that makes the whole cloud sing
I write the code that runs the onboarding
I write the code that makes the whole team smile
I write the code that writes the code
[with apologies to Barry Manilow]
I Write The Code
I like clean code ’cause it cannot lie
Sound off!
I like clean code ’cause it cannot lie.
Technobabble makes me cry.
But with a clear interface
The domain’s in your face
Intentions fall into place
You get stunned
Like getting slapped with a map
Anything less is just crap
(with apologies to Sir Mix-a-Lot)
Talking about Three Rules for Domain-Driven Design at O’Reilly Software Architecture Conference Wednesday, April 5 at 1:15pm Eastern Time in NYC.
What does software look like?
Sound off!
Did you ever ask yourself a question that was so interesting that finding the answer sort of turned into a mini-obsession?
For me, that question was “What does software look like?”
Not what can it look like, because obviously software has no predetermined visual form, but what would it look like if it had a natural, organic, 3D structure? A structure that was the same regardless of scale, from a simple Hello World to a multi-million line production system?
And what could we learn from such visualizations?
Drawing on data science as well as more traditional software analysis techniques, I began to explore this interesting visual world. The initial intent was to simply find ways of looking at software systems where anomalies would be easily spotted, as easily as you might notice a broken branch on a tree in a forest.
Slowly, connections between software visualization, software archaeology, latent semantic analysis, software refactoring, and domain-driven design began to form… along with some hints at Much Larger Problems, and study of Deep Learning.
This research is ongoing.
Update:
- The first talk was “Deep Learning for Software Development”, given at DeveloperWeek 2017 in San Francisco, CA. Siddhartha Agarwal tweeted the scary bits, and George Lawton posted an article on the talk at How deep learning and AI techniques accelerate domain-driven design after chatting over lunch.
- A more in-depth talk on this topic was given at SATURN 2017 in Denver, CO. Watch Deep Learning for Software Development on YouTube
Object-Oriented Programming Explained in 90 Seconds
Sound off!
“LIFE IS REALLY SIMPLE, BUT WE INSIST ON MAKING IT COMPLICATED.”
— CONFUCIUS
Object-oriented programming evolved from the combination of a few simple yet powerful concepts. This overview explains them succinctly.
Reading this document out loud takes me about 90 seconds, hence the title.
Procedures
Lines of code are collected into procedures and used to perform actions such as:
- feed some data in
- apply some processing or transformation
- get some data out.
Data Structures
Sometimes, some of the data elements are related to some of the other data elements, and it is convenient to group them together into a data structure, which can then be manipulated and addressed as a single unit.
Procedures + Data Structures
Now our procedure can take a data structure as its input. The procedure may alter the data in the structure and/or produce another data structure as it output.
Object, Methods, and Properties
Occasionally, we notice that some procedures are only concerned with a certain kind of data structure. It is convenient to group these procedures together with their data structure, and call it an object. This allows us to refer to a data structure and all of its associated procedures as a single unit.
The procedures associated with an object are called methods.
The elements of the data structure for an object are called properties.
Class and Instance
We may find that we need a lot of objects that behave the same but have different values for their data elements. A template for creating objects is called a class. An object is said to be an instance of its class.
Message Passing and Polymorphism
If we politely request an object to do something, instead of rudely executing its procedures directly, this is called message passing – even if no actual “message” is transmitted.
The joy here is that many different kinds of objects may respond to the same message in different ways; this is called polymorphism.
For example, we can ask many different kinds of machines to Start, and each responds appropriately. We see this every day: many different machines around us have some kind of a Start button, but exactly how they go about starting themselves is entirely up to the particular machine to accomplish.
Inheritance, Superclass, and Subclass
We may notice that one class is very much like another, sharing a lot of the same data elements and procedures. So, instead of copying and pasting code we let one class inherit from another: the subclass inherits from the superclass or “base class”.
In this way the subclass has access to all of the data structures and procedures of the superclass, and can augment or override them as necessary to define the differences between the base class and the subclass.
This process is often called differential programming; it is a very powerful and convenient way to reuse code.
That’s it! These are the basic concepts of object-oriented programming (OOP) – simple, subtle, and very powerful!
Of course, they can be misused and misapplied. This is where experience and practical advice becomes extraordinarily valuable. It’s easy to learn the definitions. It’s more difficult to know how to apply them. It’s far more difficult to recognize and fix it when you have misapplied them!
Click here to download Object-Oriented Programming Explained in 90 Seconds in PDF format.
We Can’t Compete With Google on April Fools Jokes
Sound off!
It’s difficult to prank anyone these days, especially on April 1st. We gave it a shot on this blog yesterday with Steven Lowe’s article on the imaginary programming language and platform called Unicorn. Click here in case you missed it.
Here’s how the germ of the idea started.
My school background is in I.T., not Computer Science. Steven on the other hand has been programming long before the ubiquitous computer in our homes connected to telephone jacks. So when I was quizzing Steven about software and why some program couldn’t do something, he replied, “Because that would make it magical software.”
From there I had the idea of magical software called Unicorn. When I was creating an editorial calendar for blog posts a few weeks later, I wrote down “Unicorn: The magical software that never has bugs and adds features before you know you need them” as an article topic.
One of our primary services at Innovator is custom software development. The premise of the article was to explain why that magical software will never(?) exist and consequently, why there is a need for custom software development.
It was Steven’s idea to turn the topic into an April Fools Day post. But Steven, having a highly creative and imaginative mind, as well as writing Sci-Fi stories on the side, took it further.
Instead of the usual blah blah blog post, he imagined Unicorn as the centerpiece of a Sci-Fi story. Then that funny thing happened that happens to writers when they create fiction; the characters go off-script of the original plan, diverting in different directions and spawning new ideas and connections.
Steven’s mini-epiphany was that yeah, you know what? Writing software is like writing Science Fiction. Within that Sci-Fi story are places and technologies that don’t currently exist. They have to arrive from the imagination.
You have a problem to solve, say, the need for artificial gravity within a spaceship. You create something that doesn’t exist, give it a name, and then begin to imagine how it might work.
Now what’s the process for writing code to solve a problem?
Steven says, “First you have to imagine something that doesn’t exist that solves the problem at hand. Then you have to explain to yourself how it works…then you make it work.”
The people doing this imagining are probably not writers or programmers. But they believe there’s a better, more efficient way to do things. They base their business on this change. They speak up. They pursue projects with a high level of risk. There’s another word for people like this: Heroes.
Steven will be following up on this idea of software creation as Science Fiction in a series of upcoming posts.
Mouse over to our email newsletter subscription box on the right, enter your email address, and we’ll let you know when the next article in the series is published.
P.S. No hard feelings?
P.S.S. No one noticed that the first letter in each heading spells “April Fools.”
- 1
- 2
- 3
- …
- 6
- Next Page »