Greetings Programshttp://greglturnquist.com
Searching the universe of software development for answersFri, 16 Feb 2018 20:02:38 +0000en-UShourly1https://wordpress.org/?v=4.9.465455910Why statics are no longer evilhttp://greglturnquist.com/2018/02/09/why-statics-are-no-longer-evil/
http://greglturnquist.com/2018/02/09/why-statics-are-no-longer-evil/#respondFri, 09 Feb 2018 20:47:24 +0000http://greglturnquist.com/?p=1745I used to chant the line about how static methods in Java were evil. In fact, you can find funny articles and stack Overflow discussions about how this is the case. So why am I shouting from the rooftops that statics are no longer evil? To answer that question, it’s important to realize that everything...

]]>I used to chant the line about how static methods in Java were evil. In fact, you can find funny articles and stack Overflow discussions about how this is the case. So why am I shouting from the rooftops that statics are no longer evil?

To answer that question, it’s important to realize that everything in a given language is a tool. A means to an end. The reason features take on such negative vibes is when they are used for evil. Like sharing state between objects.

When a class has a static variable, it means that ALL instances have access to this one “thing”. This mechanism was used to bootstrap things like the Singleton Pattern and the Flyweight Pattern, both things that involved a shared state between all instances that came with nasty side effects and an aversions to testing.

Singleton instances showed up in public facing APIs (even some Java standard APIs) and hence became very hard to evolve as well as test. With 20/20 hindsight, it’s crystal clear how the world moved away from these mechanisms and toward Dependency Injection. These static instances were VERY resistant to extension, testing, and ensuring a consistent state, given they had a completely different lifecycle inside the JVM compared to “newed” objects.

Hence, static were dubbed EVIL. And this led to a Butlerian Jihad against all statics.

But the landscape has changed. That previous stuff was in the era of Java 1.2 through 1.4, a time we have almost put out of our memories thanks to the leap forward of Java 5. Today we stand on the mountain of Java 8, surrounded by streams, method references, functional interfaces, and IDEs ready to transform any SAM into a lambda.

The ability to use a side-effect free function like Math.max() inside a lambda by method reference illustrates a purity we haven’t seen since Java’s inception. The ability to write small, tight functions, test them extensively, and then inject them with no risk of side effects from the surrounding object is a feature not a bug.

Let me repeat: static methods with no side effects from the surrounding objects are quite useful.

Another feature now available are static imports, making it simpler to compose functions and use them in functional flows. Being able to chain functions together without collecting in between state has let us move away from imperative programming and toward functional, reactive programming.

Static objects holding persistent state are a huge risk. They persist state between unit tests unless deliberate steps are taken to setup things up properly. In a day and age where we are trying to run either 10 or 10,000 copies of our app simultaneously, static state is NOT Cloud Native. But side-effect free static functions are.

None of this was possible with Java 1.4. That’s why statics had very little upside back in the day. So the judgment it received was most justified. If you saw “static” in someone’s code, they were probably doing something VERY WRONG. (Albeit at the direction of some of the most popular books back then). I cast that keyword into the pit myself. But today is different and to repeat the same arguments in light of Java 8 is short sighted and pedantic.

Statics are a important and we should embrace them instead of burying them under a rock.

So go forth and use statics. But do it correctly. Think: small, composable, testable functions.

If all this talk about functional flows, side-effect free programming, and method references is whetting your appetite, be sure to go grab your copy of Learning Spring Boot 2.0 2nd Edition. The entire book is written in the functional paradigm thanks to Project Reactor, and built on top of the Spring portfolio’s state of the art code base.

]]>http://greglturnquist.com/2018/02/09/why-statics-are-no-longer-evil/feed/01745Building a recording studio without breaking the bankhttp://greglturnquist.com/2018/01/30/building-recording-studio-without-breaking-bank/
http://greglturnquist.com/2018/01/30/building-recording-studio-without-breaking-bank/#respondWed, 31 Jan 2018 00:50:57 +0000http://greglturnquist.com/?p=1721Some of you may remember that in a former life, I launched a podcast with friend and former teammate, Russ Miles. Suffice it to say, that was shelved long ago. However, everything I learned came rushing back when my wife announced last year that she was auditioning with her very own publisher to record the...

]]>Some of you may remember that in a former life, I launched a podcast with friend and former teammate, Russ Miles. Suffice it to say, that was shelved long ago. However, everything I learned came rushing back when my wife announced last year that she was auditioning with her very own publisher to record the audio version of her novels. Thus launched a new project. The need for a recording studio.

You’ll need a microphone

The very first thing you’ll need is a microphone. Here is where it really pays off if you’re father-in-law has a degree in Music Ministry and has spent years recording music in his own studio. We asked him for details on a good mic, and he gave us one of his spares. In place of that, I’d suggest going out and doing a little shopping. You can easily spend $10,000 on what’s considered a “studio grade mic”. In this day and age, prices have come down and it’s easier to shop around online. Just don’t assume that something costing $9.99 isn’t going to sound equally cheap.

Cost: $50-$100 will get you something decent

You’ll need a shock mount

Ever watch a radio show streamed as video? You’ll notice that each and every microphone is wrapped in this squirrely contract. Tip: it’s called a “shock mount” and stops vibrations from getting picked up by the microphone.

Cost: $16.99

You’ll need a mic stand/boom

That shock mount needs to be attached to something. You either need to get a mic stand (we have a couple since Sara and I played in a church band for a year) or you’ll need a boom that connects to your desk. Which one you prefer really depends on your configuration. If all you plan on doing is recording books, podcasts, or videos, a boom may work wonders.

Cost: $10-$20

You’ll need a mixer

This is what will power your mic. While you can hook a passive mic (like the one that came with your iPhone) into your laptop, any serious mic needs power and laptops aren’t built for that. Good news–the simplest mixers cost about $40, and if you can splurge up to $100, you can get do all right. However, if you want a mixer to handle lots of inputs and can be controlled from your iPad, then you’ll have to spend closer to $250.

Cost: $40-$100

You’ll need a desk

When it comes time to record, you need somewhere to put your laptop, the mixer, and other things. Root around the house and see if you don’t have a tiny desk that you can repurpose. If not, visit either Ikea, Office Depot, or another similar store. No need for a fancy desk. A small place to put your stuff will do.

Cost: $40 and up

You’ll need Audacity

The software to sink your time (but thankfully, not your money) is Audacity. This open source application lets you edit audio, mix audio, clean things up, just about anything you can imagine. Learning to use it is of extreme value.

I once recorded a podcast episode and moved some questions around due to a logistical boo boo on my end. You can also edit out tiny “pops” and more. Learning to drive this app is a useful skill.

You’ll need a studio

Okay, for those of you that have seen a REAL studio, those places are incredible. They have scientifically developed wedge foam lining the walls. Sophisticated electronics. And they charge anywhere from $100-$100/minute to record material.

Since you’re not doing THAT, here is what you need: a room where there IS NO ECHO.

This may not be as clear as you realize. My wife recorded the opening chapter of her debut novel in her office, with no one else. When I listened to it, it was terrible. Not due to her performance, but the audio was “tinny”. After much scrubbing and filtering, I couldn’t improve it, deducing that the desk/walls/pinball machines/etc. had caused sound to bounce around and degrade the sound.

I took her mic and mixer board to the only room with wall-to-wall sound absorbing material…her closet filled with clothes, and did a test recording. AMAZING. No bouncing sound. No echo. No tinny sound. (The image is NOT Sara’s closet)

So I dug up a tiny desk she never used, found an extension cord, and set up all the things listed above in her closet. Following that, Sara found some opportunities where all the kids were asleep or all at school (no good recording when the 4-year-old is running around upstairs!)

So, assuming you scoop up all these things, the minimum price for all is (drum roll):

Total: $157

And you don’t have to do every step all at once. Ease into it. But know if that you want to record audio, this is the way to go. In this day and age, you really are in power to create content if that is your heart’s desire.

]]>http://greglturnquist.com/2018/01/30/building-recording-studio-without-breaking-bank/feed/01721A tale of two mediatypeshttp://greglturnquist.com/2018/01/18/tale-two-mediatypes/
http://greglturnquist.com/2018/01/18/tale-two-mediatypes/#respondFri, 19 Jan 2018 01:37:40 +0000http://greglturnquist.com/?p=1705I’ve spent the last several weeks picking up something I started back in 2015. Way back then, in the airport departing SpringOne, I started working on the third mediatype for Spring HATEOAS. There were already two: the original one based on pure Jackson and HAL. This was Collection+JSON by Mike Amundsen. As a traveling consultant,...

]]>I’ve spent the last several weeks picking up something I started back in 2015. Way back then, in the airport departing SpringOne, I started working on the third mediatype for Spring HATEOAS. There were already two: the original one based on pure Jackson and HAL.

This was Collection+JSON by Mike Amundsen. As a traveling consultant, speaker, and author, Mike has actually penned several mediatypes while also advocating for evolable, adaptable RESTful architectures. Working on this one, I made considerable progress. The progress was really about me learning how Jackson worked.

When your pull request gets turned down

You see, Spring HATEOAS doesn’t just crank out hypermedia. We have a collection of domain classes that represent a neutral format. Your Spring MVC controllers can actually be used to generate multiple forms of hypermedia. At least, that’s the idea, and in it’s formative six years of development, that premise hasn’t been dropped.

Spring HATEOAS

So after supposedly finishing the job and submitting it to the project lead, Oliver Gierke, I wondered why my work wasn’t getting merged. I chatted with him and learned of another effort afoot that was blocking its acceptance: Affordances. Another group of people were working on a very deep, extensive enhancement to Spring HATEOAS, and Oliver didn’t want to complicate things by having yet another mediatype in the baseline.

Two years later, when I rejoined the Spring Data team, I picked up the mantle of Spring HATEOAS. Oliver’s responsibilities had grown including become the official manager for the Spring Data umbrella. One of my biggest undertakings was to start reading through this Affordances API handiwork and bring it forward. Doing so required months of reading, testing, experimenting, polishing, and coding.

When your pull request gets turned down…again!

My months of effort were clobbered by the inalienable fact that the code had suffered major feature creep. It had also been forked into a couple other branches. Despite months of massaging a pull request that had over 200 commits and getting all of its tests to pass, Oliver and I agreed to shelve that work in favor of starting over.

Yes, I proposed starting over and trying to implement the same concept from scratch. If you want a hint of how long this took, you can see it in the commit logs. Because we squash pull requests, this causes the timestamps to go back to the original, first commit. This image shows code merged on November 29th, yet the commit for the Affordances work dates July 13th.

Ultimately, I crafted a much lighter weight API that allows chaining multiple Spring MVC methods together. With that, Spring HATEOAS can unpack these related links into the right format for each mediatype. For example, HAL-FORMS looks at any POST or PUT methods, finds the input type, and extracts its properties.

Testing an API by using it with another mediatype

So my big test with Collection+JSON was to take this two-year-old effort, rebase it against all of Spring HATEOAS’s improvements, and see if a completely different layout of JSON could be derived from the same vendor neutral representations INCLUDING this new Affordances API.

Step one was to rebase this entire chunk of code. Since it had previously been written against Java 6 and Spring HATEOAS was now on Java 8, that alone was a bit of effort. Several contracts had been altered meaning not all the implementations worked. Had to hammer that out.

Then in the midst of revamping things and reading the spec in detail, I noticed something unfortunate: I had completely misread the format of data. I thought turning a POJO into a simple JSON object was okay:

It looked like Collection+JSON’s “data” field would let any type of nested domain object get turned into a simple JSON structure.

Additionally, it required that I code up the ability to extract property names and values from objects for serialization, and go the other way for deserialization. This is kind of like serializing inside the serializer. Yech! But I got it done. So after several weeks, I managed to rewrite half if not more of my original code and get things working.

Next step–Affordances!

I had to hook into the Affordances API and generate custom things pursuant to this new mediatype. Two years ago, I was very aware of Collection+JSON’s “template” and “queries” sections. And I hadn’t a clue how to populate them. Until now.

This would be the moment of truth at how well I had designed this API for HAL-FORMS. Turns out, the API was quite well suited to handling this.

Coding the Affordances API, Oliver had recommended creating an AffordanceModel and AffordanceModelFactory to allow mediatype-specifics to be neatly encapsulated behind a incredibly simple interface until the mediatype’s serialization code could unpack it. Turns out that was a very good decision.

Debugging the code, I could see that a model was now being generated for both Collection+JSON as well as HAL-FORMS, and I only need one of these for any given situation. Having this complex, detailed code is most important, and handily doesn’t leak into unnecessary areas.

I had allowed some Spring MVC specifics to leak into my HAL-FORMS handlers. That was a no-go, because the whole idea is to have things be tech neutral at this point.

One of my last tests was to have one Spring MVC controller wired up, and have it serve queries for two different mediatypes.

With this in place, I began to engage in classic jürgenization. This has taken me several days. I discovered a missing pair of units (serialize/deserialize custom extension of ResourceSupport) and hence missed a critical corner case. Crisis averted, I have pushed off the final set of commits to Travis CI and submitted it to Oliver for review.

Using one mediatype to develop another

Having built HAL-FORMS, I enjoyed leveraging all the lessons learned to build up Collection+JSON. It gave me a starting point for tests that needed to be written, a nice repeatable pattern of serializers and deserializers that also had to be tackled.

And having just recently performed the work for HAL-FORMS, I was ecstatic that when I solved a particular problem for Collection+JSON, I was able to refactor HAL-FORMS to use the same solution, ensuring consistency between the two.

Every time I work on another mediatype, the whole project gets stronger, better, more reliable. That’s why I can’t wait to circle and resume my efforts with UBER Hypermedia. Most of the work is done. Or at least, that’s how it appeared when I was last there!

But I wanted to let it rest, and circle back. WIth three mediatypes implemented (HAL, HAL-FORMS, and Collection+JSON), UBER will be a real sizzler. After that, SIREN, and then possibly XHTML.

]]>http://greglturnquist.com/2018/01/18/tale-two-mediatypes/feed/01705How TDD is wronghttp://greglturnquist.com/2017/11/14/how-tdd-is-wrong/
http://greglturnquist.com/2017/11/14/how-tdd-is-wrong/#commentsWed, 15 Nov 2017 00:04:08 +0000http://greglturnquist.com/?p=1644I’m a pretty big test advocate. After all, it’s in my profile. So how can I say that TDD is wrong? “Test-bitten script junky…” — opening of my profile The “test-bitten” means I’ve been bitten by the automated testing bug. In a previous post, I mentioned having built the equivalent of a CI solution...

]]>I’m a pretty big test advocate. After all, it’s in my profile. So how can I say that TDD is wrong?

“Test-bitten script junky…” — opening of my profile

The “test-bitten” means I’ve been bitten by the automated testing bug. In a previous post, I mentioned having built the equivalent of a CI solution early in my career without knowing it. So how can I advocate such a heretical point of view?

The answer is subtle. To me, the benefit of automated testing is in having the testing and automating it.

Nowhere do I see primary benefit in writing the test first.

Nowhere do I see it better to write the test then write the code that solves the test.

Transitioning into my current role on the Spring team has moved me into the land of framework design. Building frameworks is quite different than end-user apps. That’s because the code you write is meant to serve not one but many. And in the case of Spring, we’re talking millions of developers (no exaggeration).

When serving this many people, you are building APIs, implementations of APIs, and ensuring that all kinds of scenarios don’t break that API. So I often have to start writing the API first. I try to create some fields. Add the accessors I need. Try to chain stuff together. And then I begin to write test cases that poke at it.

Several Spring projects also use Project Lombok. This is a really neat toolkit that I’ve known about for years, but only in the past two years have I truly come to appreciate it’s power. It makes it possible to stop writing getter/setters/equals/hashCode functions, customize visibility of accessors, define data classes, value classes, builders, and other stuff. All with a handful of easy-to-read annotations.

Trying to write a test case and then writing a Lombok-based class is ineffective. I’d rather create the class first and then use it’s pre-packaged structure in the unit test. Using Lombok in this way ensures a lot of very consistent structure that makes the overall API easier to consume. For example, it’s Builder annotation produces an API that looks like this:

This example is the builder I defined for the hypermedia format of Collection+JSON. It lets you lay out all the parts of a CollectionJson record, which is then serialized into JSON. The class behind it looks like this:

This class has several things, so let’s take it apart.

@Data and @Value create setters and getters, along with equals, hashCode and toString methods. This is the core for a Java object, but not the bits directly needed for a builder.

@Builder creates the fluent builder shown earlier with collectionJson the static function to create a new instance of this class.

@JsonCreator is simply used to connect Jackson to this class when it comes to deserialization.

And because the Item class is also a builder, I have item() as a convenience method to dive into this “sub” builder.

That’s it! This class is highly coherent because there is little “code” as in logical stuff being done. Instead, it’s mostly declarative. This class isn’t buried in logic, because it’s focused on defining a data model.

I can’t imagine noodling my way through this in a unit test and then trying to bend Lombok to support my test case. Like I said, it’s easier to define all the properties (version, href, links, and items), then flagging it as a Builder, Data, and Value class. Go into the unit test code, and start using it. Avoid much heartache.

And because I can still submit pull requests with gobs of test cases, achieving 100% coverage of things, I see little value in this “test first” approach advocated by TDD.

So…am I wrong? In what way? Jump in on the comment cause I’m dying to hear.

]]>http://greglturnquist.com/2017/11/14/how-tdd-is-wrong/feed/11644Why I converted a Gradle project to Mavenhttp://greglturnquist.com/2017/11/07/converted-gradle-project-maven/
http://greglturnquist.com/2017/11/07/converted-gradle-project-maven/#commentsTue, 07 Nov 2017 15:55:37 +0000http://greglturnquist.com/?p=1626It may sound quirky, but I had finally HAD IT with a project I manage: Spring Web Services. There were several aspects of the build file that kept getting in my way. Well, I was about to embark upon a critical change from which Gradle pushed me over the edge. To the point that not...

]]>It may sound quirky, but I had finally HAD IT with a project I manage: Spring Web Services. There were several aspects of the build file that kept getting in my way.

Well, I was about to embark upon a critical change from which Gradle pushed me over the edge. To the point that not only did I convert to Maven, but ALSO moved the reference documentation from DocBook to Asciidoctor.

So what’s wrong with Gradle?

I know this is controversial, but I have worked with many projects. On the Spring team, it’s a common paradigm that if you need either a feature or a bug fix applied to some aspect of the portfolio, you check it out and submit a patch.

The community embraces this, and sometimes, if you really need something, the fastest route is to do it yourself.

Many use Maven, many use Gradle. I don’t mind Gradle for the occasional patch request. But when it came to an up-and-coming switch Spring Web Services had to make, Gradle wasn’t going to cut it.

Spring Web Services was going to create a new major release. We had supported 2.4 for a couple years, and 3.0 was about to get launched. This was the version where I could bump up the minimum to Java 8, Spring Framework 5, and other key 3rd party libraries.

That wasn’t the tricky part. The fact that we had to maintain the 2.4 branch at the same time, meant I needed a simpler build model.

Gradle comes loaded with a programming model that lets you declare things, and then hook in extra code to tailor things. And that is the problem!

Declarative vs. programmatic

Maven has this pattern of declaring what you want, and it goes and carries it out. You declare things like:

Artifact coordinates

Dependencies

Plugins

Because people frequently need to adjust settings for different scenarios, Maven supports the concept of profiles.

Gradle starts with the concept of a declarative build system as well. You can also declare:

Artifact coordinates

Dependencies

Plugins

But guess what? No first class support for profiles. Most people say, “no problem! Just code it.” Gradle uses Groovy, so you can write a little glue code, and BAM you have the concept of profiles.

Why do I need profiles? To make backwards compatibility maintainable, I always test each patch against the latest GA release of Spring Framework, as well as the latest snapshot release and the next major version. Each of these, captured in a separate profile, allows me to command my CI server to run every single patch across multiple versions of Spring Framework/Spring Security, and verify I’m not breaking anything.

Gluing this together with Groovy code was okay when I maintained a single branch. But migrating into maintaining two branches (master for 3.0 stuff and 2.x for the 2.4 stuff), that frankly wasn’t going to cut it. You see, Maven profiles are supported inside IntelliJ IDEA, but some glue code that emulates the same concept in Gradle doesn’t work AT ALL. It drives me to use the command line when my IDE should be supporting me.

This isn’t the only thing I’ve seen Gradle come short on where one must write code in their build file.

Frankly, I don’t WANT to write code there. That’s what I was able to do with Ant, and Ant drives one to spend too much time in the build file. Gradle is by no means as bad as Ant, but it seems a tad ant-ish.

Anything else?

Since you asked, there is another irritant. Gradle has plugins and that is great. Except that the blocks they add to your build file are at the global level. That means any construct you spy with settings inside it doesn’t identify the plugin they came from. You want to debug some piece of the build? You can’t jump to the plugin’s docs. You must first rummage around Google to determine which plugin is at hand.

To drive my point home, I’ve checked out projects where the developer built a handful of custom gradle plugins. That’s nice and handy, but it raises the need for me to READ every single plugin to know what’s happening.

Frankly, I’d prefer a block of XML, where the coordinates of the plugin AND its configuration details are RIGHT THERE. Maven may not offer the same magic of codability, but I fear that feature is shadowed by lack of discoverability.

Why the hate?

Okay, I know that Gradle is pretty cool out there. Many have been driven over the cliff by Maven. But to be honest, I haven’t seen enough payoff to warrant sticking with Gradle.

Since I could be wrong, feel free to dive into the comments and give me your pluses and minuses about Gradle vs. Maven!

]]>http://greglturnquist.com/2017/11/07/converted-gradle-project-maven/feed/21626Learning Spring Boot 2nd Edition released!http://greglturnquist.com/2017/11/01/learning-spring-boot-2nd-edition-released/
http://greglturnquist.com/2017/11/01/learning-spring-boot-2nd-edition-released/#respondWed, 01 Nov 2017 18:25:52 +0000http://greglturnquist.com/?p=1631I’ve been working on this for over a year, and today is the day. Learning Spring Boot 2nd Edition released! What’s in it? A whole lot: Web Development Data Access Testing Developer Tools AMQP Messaging Microservices WebSockets Security more! To top it off, the WHOLE BOOK is written using the new Reactor paradigm found in Spring...

To top it off, the WHOLE BOOK is written using the new Reactor paradigm found in Spring Framework 5.0. This means Reactive Web, Reactive Data Access, Reactive Messaging, Reactive WebSockets, and even Reactive Security, all groundbreaking technologies.

In fact, the following key technologies are used through the book:

Spring Framework 5.0.0.RELEASE

Spring Data Key-RELEASE

Reactor Bismuth-RELEASE

Spring Boot 2.0.0.M5

Spring Cloud Finchley.M3

There isn’t any other book on the market like this. And not only is this a fantastic stack, but in each chapter, we build up a social media platform. Chapter by chapter, we add critical features for demonstration purposes, and in the process, are able to learn how to do these things reactively, in ways you can easily adapt to the problems you are solving today.

In short, not only is it groundbreaking, it’s practical and pragmatic. Coding examples you can put to work immediately in whatever you are trying to solve.

It may take a little bit of time to get pushed all the way the Amazon, so stay tuned.

]]>http://greglturnquist.com/2017/11/01/learning-spring-boot-2nd-edition-released/feed/01631How @ATT almost conned me into buying fiber internet at my househttp://greglturnquist.com/2017/10/17/att-almost-conned-buying-fiber-internet-house/
http://greglturnquist.com/2017/10/17/att-almost-conned-buying-fiber-internet-house/#respondTue, 17 Oct 2017 18:35:07 +0000http://greglturnquist.com/?p=1624Last week, a salesman knocked on my door from AT&T. Ready to shoo him away, as I had done for the past four years since moving in, he indicated he was here to sell AT&T Fiber. “What?” The only salesmen I’d seen to this point were hawking AT&T DSL or as they rebranded it, AT&T...

]]>Last week, a salesman knocked on my door from AT&T. Ready to shoo him away, as I had done for the past four years since moving in, he indicated he was here to sell AT&T Fiber.

“What?”

The only salesmen I’d seen to this point were hawking AT&T DSL or as they rebranded it, AT&T Uverse. I work at home. I absolutely do NOT need that terrible latency of internet traveling over copper phone lines. So discovering that fiber was available, simply not offered due to capital overhead, stirred my interest.

I asked many pointed questions, like why now? He indicated that fiber was in some of these newer neighborhoods, but to hook it up back at the center took a bit of capital outlay, so they had waited until there was enough consumer interest. We switched to price, and I discovered I would save $100/month off my cable internet bill.

I signed on the dotted line.

That was last Friday. This is today, an hour after the service tech has left my house.

You see, she showed up at noon to wire things up. I kept waiting for her to start digging the trench the sales guy had indicated to run the fiber line to my house. Always interested, I asked her about it.

“I don’t need to do that.”

I blinked. “What? Don’t you have to dig a trench to hook up the fiber?”

“There’s no fiber in this neighborhood.” She didn’t hold anything back.

“What are you hooking up?”

“AT&T Uverse. 50 down/10 up.”

That is NOT what this guy said. I asked had asked him about 1000MB service, and he had nodded at me. In fact, when the work order arrived in my inbox an hour after he left it read “ATT 50”. Perplexed, I had called him and asked, “Why does it say 50?” His response? “It says 50, but the tech will hook up fiber.”

Well that was a direct lie. To my proverbial face.

The tech nodded at me. “I hear that twice a week. There’s fiber running to the street corner.” She pointed at the major intersection 400 feet away. “But people just here ‘fiber’ and go for it. We’ve complained to their sales managers to try and put a stop to that.”

The tech was real gracious. She stopped while I left a voicemail message with the sales guy that had conned me big. After packing up, she actually asked for the name of the sales manager so she could give it to her manager. As if that will help. The guy was a bit young, so probably carrying the bidding of his manager.

Nevertheless, I feel bad for the non-tech people all around me. All these friends and neighbors of my community getting ripped off by these lies.

And I’m a little embarassed that I got taken in. But I’m actually more mad than anything. Mad enough to blog about it and hopefully tip off someone else.

So in the meantime, burn AT&T. You earned it with your slimy Empire-like sales tactics.

]]>http://greglturnquist.com/2017/10/17/att-almost-conned-buying-fiber-internet-house/feed/01624Why every press needs a code monkeyhttp://greglturnquist.com/2017/09/30/every-press-needs-code-monkey/
http://greglturnquist.com/2017/09/30/every-press-needs-code-monkey/#respondSat, 30 Sep 2017 20:35:30 +0000http://greglturnquist.com/?p=1618It’s not secret that I’m writing a novel. (If you HAVEN’T heard this, then I’m just not communicating very well!) It’s scheduled for release in March with a relatively small press called Clean Reads. And its owner wears many hats. An author herself, the owner of Clean Reads is also an editor, content manager, graphic...

]]>It’s not secret that I’m writing a novel. (If you HAVEN’T heard this, then I’m just not communicating very well!) It’s scheduled for release in March with a relatively small press called Clean Reads.

And its owner wears many hats. An author herself, the owner of Clean Reads is also an editor, content manager, graphic designer, mother, aunt, and many other things. But I think you get the idea. She is fundamentally running the press herself with a handful of freelance editors and cover artists.

Anything missing in there? Oh yeah. Her press has a website. Did I mentioned she’s a code geek? A bit burner? A web designer? No? Well that’s because she isn’t. So what has happened because of this? What happens to every business caught up in the 21st century stuck with 20th century business practices.

She has been doing the best she can with Facebook, Twitter, and Instagram. Ahh, the good ole social media triumvirate. We keep hearing word that you must get on social media if your business is to succeed.

Well that’s one big lie.

Social media is a channel to reach people, but since the inception of Facebook, it has steadily gone down hill. How? In the beginning, when someone “liked” your group, they would then get EVERYTHING you posted. Today? They might get 10%. Unless you pay Facebook a little deneiro.

People that built up empires of followers on Facebook years ago, watched their sales plummet as they could no longer REACH their followers. That is, until Facebook started extorted…err…charging money to reach YOUR followers. Evidence that they aren’t YOUR followers but Facebook’s.

My wife’s research into social media revealed one author that took a three month break from writing. To do what? That’s right, focus on facebooking, tweeting, and instagramming. And in three months of effort, got maybe a 30% reach of her social media followers. Yikes!

This is why it is SO important to build a mailing list. A website you control and a mailing list that reaches EVERYONE is the most important thing you can build for your business. And if you don’t know how to stand up a website and configure it to harvest emails, you will be left in the cold.

At the Kentucky Christian Writer’s Conference, I met my publisher face to face. We chatted over lunch. And in the midst of that, is when I learned that Stephanie needed help raising her website from the ashes of a previous outage. They say never pass up an opportunity, so I haggled out a deal where she’d remove a certain criteria she had for going to paperback, and I’d get her website operational. With a handshake, I got on the ball.

Since then, we have loaded over four hundred backlisted titles along with cover art and e-books. Visit the site and you can BUY books. Join our newsletter (trust me, you’ll get the opportunity if you visit), and you’ll get a super secret coupon code to buy ANYTHING at 20% off.

I’m not here so much to hawk that site, as to instead hawk the idea that when you form a business, whether it’s a publishing press or ANYTHING ELSE, you need SOMEONE that can do this stuff. I know WordPress. I’ve used it to run my blog for years. It’s not perfect, but it gets the job done. With a little sweat equity and some time reading tips and tricks, you can really put out a decent store for your business.

If you are even THINKING of running a business in the 21st century you need to:

Learn how to standup and run a WordPress site (an independent consultant could cost you $10,000 easily)

Start building a newsletter

Use Facebook and Twitter. Don’t let them use you. The idea is to make money for YOU, not be the one making money for THEM.

]]>http://greglturnquist.com/2017/09/30/every-press-needs-code-monkey/feed/01618Learning Spring Boot – 2nd Edition Rewrite is completehttp://greglturnquist.com/2017/09/18/learning-spring-boot-2nd-edition-rewrite-complete/
http://greglturnquist.com/2017/09/18/learning-spring-boot-2nd-edition-rewrite-complete/#respondMon, 18 Sep 2017 23:17:58 +0000http://greglturnquist.com/?p=1614I have finished updating every chapter of this book to the Reactor-based paradigm. And boy did it take a lot! In case you missed it, when I embarked upon writing this book for Packt Publishing, I decided to start from scratch. The previous edition, as much as I enjoyed it, wasn’t bold enough. This time,...

]]>I have finished updating every chapter of this book to the Reactor-based paradigm. And boy did it take a lot!

In case you missed it, when I embarked upon writing this book for Packt Publishing, I decided to start from scratch. The previous edition, as much as I enjoyed it, wasn’t bold enough. This time, I wanted to build an application chapter by chapter, and make it as real as possible.

So I dug into a demo app I had used at several conferences called Spring-a-Gram. That app started from my desire to snap a picture of the audience and upload it to the website, LIVE. Great eye candy, right? Along the way, I learned lots of aspects of the Spring portfolio that this app could leverage.

And when faced with the prospect of writing a new title on Spring Boot, I picked up and ran with that app. Only this time, EVERYTHING would be done asynchronously and without blocking, i.e. with Reactor, Pivotal’s implementation of the Reactive Streams spec.

So this book is stocked with asynchronous web, data access, AMQP messaging, WebSockets, microservices, security, metrics, developer tools, and production tips. A solid cross section of what developers need to build apps.

The trick with this lauded goal is that when I started writing about 15 months ago, there was no Spring Boot 2.0. Spring WebFlux was being scratched out in an experimental repository. Spring Boot WebFlux starters appeared later in a different repository.

Talk about taking on a risk!

So I started writing the manuscript using Boot 1.4 and servlets, with plans to rewrite everything once the Reactor bits were available. That has been a LOT of effort, but worth it.

Because I’m quite proud of being able to show people how to build apps rooted in Spring, the de facto Java toolkit for application development, but now sitting atop Project Reactor, the bedrock of Reactive Streams apps.

Until yesterday, we were focusing on Spring Boot 2.0.0.M4 as the release target, but decided to wait for 2.0.0.M5 coming in a couple weeks, with plans to polish, revise, and release around the second week of October.

Hopefully we can hold onto that release date! There appears to be high demand for what will be the first book on Spring WebFlux as well as Project Reactor to hit the markets.

I’m excited to get this book into everyone’s hands and watch as people began to write scalable apps with Reactor on top of the Spring portfolio.

]]>http://greglturnquist.com/2017/09/18/learning-spring-boot-2nd-edition-rewrite-complete/feed/01614OOP is dead, long live OOPhttp://greglturnquist.com/2017/08/11/oop-is-dead-long-live-oop/
http://greglturnquist.com/2017/08/11/oop-is-dead-long-live-oop/#respondFri, 11 Aug 2017 17:22:04 +0000http://greglturnquist.com/?p=1595Raise your hand if you remember the golden hammer of Object Oriented Programming. You know, where you only have to code something once and then reuse it in all your subclasses? Remember those days? Maybe this is what they still teach in dusty lecture halls amidst today’s Computer Science departments. But if you have spent...

]]>Raise your hand if you remember the golden hammer of Object Oriented Programming. You know, where you only have to code something once and then reuse it in all your subclasses? Remember those days?

Maybe this is what they still teach in dusty lecture halls amidst today’s Computer Science departments. But if you have spent any significant time coding in the trenches, you will have come to realize the lie that this mantra is.

You see, grandiose hierarchies of objects over time become nigh impossible to manage. At a certain point, one more subclass bolted onto the grand structure is deemed impossible and you must fork the solution. No, there is a different structure out there that we must adopt. And Spring is the platform that carries its banner.

Interface Oriented Programming. Let’s call it IOP since there aren’t enough acronyms in our industry. IOP is the premise that different slices and layers should talk to outsiders through a nice, clean interface. The backing service on the other side should provide a concrete implementation, but the caller need not know about it.

Why do I mention Spring as the champion of IOP? Because Rod Johnson’s foray onto the Java scene was to craft a dependency injector whereby this interface-based contract could be satisfied. Before I learned of Spring, the concept of Java interfaces was foreign. Sure they were mentioned in my college textbook Java in a Nutshell (dating myself?) but I saw little value in using them. Why?

Because when you are “newing” everything yourself, there appears little value in defining an interface and then assigning the object to it. You already know what is! What is to be gained from all the extra typing? But delegate that task to a DI container, and suddenly the cost vanishes. Expressing dependency graphs between beans with interfaces becomes much smoother when the container takes over the job of creating everything.

This goes along with the Liskov Principle where you can plug in any implementation without knowing what it is. Now sometimes people drag out the old square-is-a-rectangle example. I hate that one because geometry is a terrible domain to model semantic software concepts.

Digging in, interfaces don’t have to be complex. Instead, think of a handful of “getters” and go from there.

This fragment is part of an ongoing effort to add Affordances to Spring HATEOAS. Since we might support multiple web frameworks, having a clean, unencumbered interface is critical for getting started. It also helps avoid saddling the interface with details from Spring MVC, Spring WebFlux, or JAX-RS. Instead, this interface avoids all of that, forcing the concrete details to be nicely contained apart from each other.

Abstract classes and long hierarchies are often tricky to evolve over time, so I try to dodge that as much as possible. Composition of objects through IOP-driven strategies tends to be more amenable to change. Having said all that, what happens when you need this?

This is ONLY an abstract class because the project is currently on Java 6 and we can’t plugin a default implementation for supports(). With Java 8, this whole thing can be rolled back into an interface. Abstract vs. default interface methods aside, this is the NEW OOP. Do as much as you can to code 1 interface-to-many classes, avoiding intermediaries. Sometimes it’s unavoidable, but don’t give up too fast.

Let IOP be your OOP.

And the more you learn about the whole code base, be willing to revisit some of those hierarchies and see if you can’t “move around” stuff to get away from the hierarchies. You might be surprised at how perky your code becomes. Some of those requested features might suddenly seem possible.