Author Archives: Greg Turnquist

How @ATT almost conned me into buying fiber internet at my house

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.


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.

Why every press needs a code monkey

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.

Stay safe out there!

Learning Spring Boot – 2nd Edition Rewrite is complete

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.

So stay tuned! The end is in site.

OOP is dead, long live OOP

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.

The power to say no

One of the most important things we can do is to say no. A lot of things arise in work, in life. And the hardest thing is to sometimes say no. To indicate this shouldn’t be done. To voice our objection. Not argue, just say no.

Since Berlin, I have been working on adding Affordances to Spring HATEOAS. We’re talking a feature branch that has over 200 commits from the original author. The effort was pursued a couple years ago. It stalled out because no one on the team had time to champion this effort. Another team of developers actually forked the branch and added more. Finally, I joined earlier this year and started reading this vast sum of new code.

And I read, and read. And read. And. Read. We’re talking three months of reading, editing, polishing, changing, and rebasing. Did I mention reading?

So earlier this month, Oliver and I have a Google Hangout code review. I have pushed this code as far as I can. I have polished as much as possible. But when it comes time to defend it before my manager, one who maintains almost as high of a coding standard as Juergen Holler, things quickly fall apart.

“I just see piles and piles of code,” Ollie said. And I nodded along. He was right. I didn’t want it to be true, but it was clear. He quickly spotted my sample where both a PUT and a PATCH were shown, the outcome that one method required every parameter, while the other required none.

“Couldn’t we spot the method and flip that bit automatically?” he asked. More nodding from my end. He was gosh awful right. And I knew this current branch of code was never getting near the master branch.

So what did we do with three months of effort? We regrouped.

“What if we start clean? The serializers for HAL-Forms are solid. Why don’t we work on a fresh Affordance API, and see how much of Spring MVC we can leverage to find the other details?” I said.

And here I am, two weeks later, closing in on a feature branch. It includes HAL-Forms mediatype plus a VERY lightweight API for defining an Affordance.

This small bit of Spring MVC + Spring HATEOAS code is lifted from a test case.

  • It’s the handler for a GET /employees/{id} call.
  • It creates two links: self and employees.
  • Using a new method (withAffordances) and a new utility method (byLink), it has access to everything about this the PUT and the PATCH operations, and can glean the attributes needed to run those two methods.

And it doesn’t involve piles and piles and piles of code. I think I spent two days trying to model where these “Affordances” would live. (Ended up in the Link itself, since a Link can have one or more). I spent another day or two digging through the method invocation to build these links, and harvested extra Spring MVC details, like the route, the incoming request body’s type, and a little more.

I think I’ve spent maybe two days ensuring these bits of code don’t intrude on each other. For example, the code that reads Spring MVC annotations isn’t part of the Affordance interface. That will make it easier to write a JAX-RS version down the road. We also need to support Spring WebFlux at some point as well. And the Affordances stuff cannot leak into the mediatype.

So focusing on getting single resource, collections of resources, and pages of resources working has taken a total of maybe two weeks. (Today was the day I got pages working).

Oliver is quite excited about this. As am I. This will set the pace for implementing other hypermedia types. We currently have HAL and are adding HAL-Forms. Coming: Uber, XHTML, and SIREN. And when these arrive, they will become available to Spring Data REST.

Additionally, my handful of PRs I worked on over the past three months are ALSO getting reviewed, so there is indeed a lot of motion of Spring HATEOAS.

I’m really happy Oliver say “no”. Remember, it’s your option to say as well. Just be ready to defend it with all your might.

Streams of messages are the way to go

I have been diligently getting all my code up to date for the release of Learning Spring Boot 2nd Edition this September. Digging into Chapter 8, WebSockets with Spring Boot, I realized I had a bigger challenge than expected.

You see, I’d chatted with Rossen, the lead developer on Spring Web. In the past, his job was overseeing Spring MVC, but in the past year, that has expanded to our new Reactive Streams story and the module Spring WebFlux. In short, Rossen informed me that there was no messaging available with WebSockets in WebFlux.

I’m not sure you’re aware what this means. “Message” was a paradigm invented by Mark Fisher in the early days of Spring Integration with a nice little container class called Message<T> that included a payload and optional headers. This was handy when it came to enterprise service buses, but people spotted the paradigm as more universally applicable.

Hence, they put a messaging layer on top of WebSockets, making it super easy to pipe messages from clients to the server and back. Anywhere in the server side code, you can get your hands on a SimpMessagingTemplate and publish a message, targeted for either a server side or client side endpoint. The runtime would handle it all.

And none of this was available with Spring 5’s WebFlux-based WebSocket solution. As Rossen said, “think of it as streams of WebSocket messages.”

That was tricky.

So I dug in and started learning the API. In the reference docs, they show how to register a WebSocketHandler. You tie that API to a URL and inside the API, are handed a WebSocketSession. I kind of stared at this API for five minutes before noodling around with it.

Unsure about what to do, I cracked open the Spring Framework source code and started reading their unit tests. Since my chapter had a “chat” server (the de facto demo for WebSocket technology), I was ecstatic to see something similar right there in WebFlux’s unit tests. It was an EchoServer.

I copy and pasted the code into my book’s code. Tweaked the JavaScript to hook up. Fired things up, and started sending in messages. And it worked.

Until I opened a second tab sporting a different WebSocket session. That’s when I noticed that the messages posted by one tab didn’t appear in the other.

And then I KNEW what they meant by “EchoServer”. Receiving the messages on a session and sending them right back ONLY WORKS ON THE SAME SESSION.

I shook my head, remembering the fact that Spring 4’s WebSocket configurations SHOWS you configuring a broker. That’s what is needed!

I needed a broker and I didn’t have one. At this point, I had gotten barebones WebSockets registered on the server and my client connected. But to noodle this thing out, I stopped to get a coffee. As the java was brewing, so was my noggin. That’s when the light bulb went off.

I already had a broker. It was right there.

You see, I had gambled on putting Spring Cloud Stream in my book when it was in its infancy. In Chapter 7, AMQP Messaging with Spring Boot, I kick things off with Spring AMQP’s RabbitTemplate, which is great for small stuff. As if often the case Spring’s template approach makes the AMQP APIs very pliable. They also adopted the Message paradigm from Spring Integration so you can either send your own POJOs, or you can do it Message<Pojo> style, which moves your abstraction up a level, making things simpler.

But Spring Cloud Stream is even better. It moves things up even higher. You aren’t thinking in terms of message brokers. Instead, you are thinking about chaining together streams of messages. (Which, by the way, dovetails PERFECTLY with Reactor).

Whether you are using RabbitMQ or Kafka (or whatever) is simply an implementation detail. With a few property settings, you can put together any sort of messaging you want.

And I was already doing that!

Now I’m no genius. This is stuff that had I just spoken with Rossen and Marius (lead for Spring Cloud Stream) they would have pointed out in no time. But there is that thrill of discovering something for yourself that is unbeatable.

So I hammer away at a service that listens for WebSocket messages and pipes them into a broker via Spring Cloud Stream. (Thanks Artem for showing me to do THAT with Reactor!) I code another Spring service that listens for a stream of messages coming from the broker and pipes them out to a WebSocket stream.

And I’m done. In maybe 20 minutes. (I did goof up by not pointing these two servers at the same AMQP exchange).

I fire up my system, and the chat service is working. Flawlessly. A message written in one tab is shipped over a WebSocket to the server. The server pipes it into RabbitMQ. The other service scoops up the message, and pipes it out to the WebSocket client. And this is happening for every WebSocket session that has registered. This thing is a knockout punch, because I knew I architected it right.

Poof! (Plus, the concept feels totally righteous. Streams of messages, flowing through the system.)

That’s when another realization hits me. When I previously drafted this chapter, I attempted to use Spring WebSocket’s RabbitMQ option, but never could get it to properly bind to my RabbitMQ instance. Sadly, I switched to their in memory broker. This meant the solution wouldn’t work if you ran multiple instances in the cloud.


Because it’s piping stuff right into RabbitMQ, it will work perfectly. (Partly thanks to Consumer Groups).

To wrap up the chapter, I even went so far as to show off SimpMessagingTemplate’s sendToUser API. It nicely lets you send a message to a single user. I coded a little “@bob Did you get this?” magic, where it would parse the @’d user, and then convertAndSendToUser(parsedUser). Well, I had none of that API, remember?

How can I pull this off? Must be too much, right? Wrong! Since every message is traveling to everyone, and it’s using the Message<T> construct, it takes no effort to add a header including the original user’s name.

The broker-to-client service can simply parse the message and compare against the user or themselves, and decided whether or not to let it on through. (Send a copy to both parties!) It’s basically an extra filter layered on top, which is why Reactor makes this type of thing so easy to apply.

Anywho, with a solid day of work, I manage to code the entire thing, top to bottom, using RabbitMQ, WebSockets, Project Reactor, and even have user-to-user messaging. Freakin’ wicked it was to put it all together.

And I know this is rock solid not because of what I coded. But because of the powerful underlying concepts orchestrated by Rossen, Mark Fisher, Artem, Gary, and Marius.

Can’t wait to apply security filtering in the next chapter to these WebSocket streams.

Learning Spring Boot requiring more tweaks to get off the ground

With things bearing down on my September due date for Learning Spring Boot 2nd Edition, I’ve gotten in gear and started hammering at the codebase.

For one thing, I have strived to catch up ALL the code to Spring WebFlux, no longer using the servlet-based Spring MVC. In the process of doing that, I discovered a breaking change in Spring Framework that conflicts with the latest milestone of Thymeleaf. I switched to snapshots, and moved forward.

The big change coming down the pike has been WebSocket support. In Spring 4, there is incredibly detailed support for various messaging protocols, messaging brokers, and all sorts of goodies involving Spring’s WebSocket support.

With Spring WebFlux, they had to start from scratch and build things up. Suffice it to say, streams of WebSocket messages in and out has a very basic API. Hence, I’m rewriting the code in Chapter 8 to leverage this, chuck aside things like STOMP and SockJS. I rewrote the server side code thanks to the project lead of Spring Integration, and revved up to test it out, only to get stymied by something else.

Somehow, Reactive Web was switched off in favor of Servlet Web.


Spending a couple hours on Slack with some super sharp teammates, I uncovered a dependency from Spring Cloud Netflix that pulled in Tomcat along with another transitive dependency on Spring MVC. Excluding them got things humming again on Netty, only to find a bug in Thymeleaf caused by Spring WebFlux + Spring Cloud Stream.

Sigh. I updated the issue filed with Thymeleaf asking about another release to see how to move forward. Until then, this book is paused. Yet again.

When that is fixed, hopefully I can push forward and get the last bits in line.


Facebook marketing ain’t what it used to be

I have recently been learning a bunch about marketing. My wife has started marketing her fourth novel. Along the way, we have also started boosting Facebook posts about the freebie opportunities. And in my quest to better understand these types of campaigns, I have stumbled into a concept called “organic reach”. That is cute language for “reaching people without spending a nickel.”

“Organic reach on Facebook has been in decline for a few years now and has almost hit zero. If you want to break through now, Facebook is all but a pay-to-play network.” —The Complete Guide to Facebook Advertising

In the olden days, people would “like” your group/page and then see anything you posted there. Today, not so. Facebook has algorithms that “decide” what shows up in people’s feeds. Sponsored postings can interrupt a newly minted post on your page that a friend liked, causing them to miss content.

Yup. Someone that you catered to, who decided they liked your content, isn’t guaranteed to see everything posted on that page. Suffice it so say, many are up in arms over this. It backs up a rule I teach at any of my Blogging & Marketing sessions – build your own platform.

Yes. Build your own platform. Craft a site. Curate a mailing list. It will take awhile, but in the long run, you will be running things your way. Sure, you will continue posting things to Facebook, Twitter, and what not.

But don’t presume that the rules of yesterday and today won’t be different tomorrow. Such are the woes of using other people’s platforms.

The “spice” of Pre-Edits

This blog post is coming to you late because I’m neck deep in pre-edits. Since I signed a contract for Darklight, I have had a checklist of things to get done for my publisher, Clean Reads. The most exhausting: pre-edits.

Pre-edits are an opportunity to clear away the proverbial brush. There are LOTS of things we authors do when banging out a first draft.

  • Start three sentences in a row with the same word
  • Use adverbs ALL OVER THE PLACE
  • And use that insidious word “very” WAY too much. In fact, that word is so overused (without conveying any extra meaning) that my publisher makes no promises about what will happen if she sees it in a manuscript.
  • Point of View violations
  • Commas, commas, and commas

I can tell you right now: I LOATHE PRE-EDITS! I am slogging my way through the manuscript AGAIN. Trying to polish it up. (That’s what I’ve done multiple times over the past year, if not years).

Taking a calming breath, it’s important to understand that my publisher isn’t out to get me. Instead, she wants to clean up the stuff that can be easily sifted through out of the way. That way, my editors can focus on deeper, more important stuff. Like…

  • Does the story evolve in a way that holds the reader’s interest?
  • Are there too many points of view in the story? Not enough?
  • Does the dialog balance the prose well?

Stuff like this helps take a “neat idea” and catapult it. Readers may not “know” all this writing craft, or how to name it. But trust me, readers can tell a good story from a great one. (And a badly written one as well).

So for the umpteenth time, I am walking through Darklight, scene by scene, trying to clean out obvious junk and give it a final buff before I ship it off. And considering its due in 48 hours, I even took this week off to focus!

As Baron Vladimir Harkonnen likes to remind us, he who controls the spice controls the universe. Well we are the ones in charge of the spice of our novel, and having good writing without clunky junk in the way is the path toward a universe of excited readers.

Happy writing!

Why do we need experts?

In this day and age, the DIY (Do It Yourself) movement is strong. The internet has made it super simple to start reading about somthing, but a few things from Amazon, and reach and get going! On one hand, that’s really good. I’ve seen countless businesses launched in this fashion. Many show up on Shark Tank. But sometimes, we need experts. Sometimes we need people with a very focused sense of knowledge, and if we don’t hire them, we’ll end up either paying too much, or losing out on opportunity.

Real Estate Experts

I have a handful of rental properties. In fact, it’s the principal part of my retirement portfolio, given 401K funds don’t work. Every month, my tenants send in a check to my property manager. Property manager collections 10% fee, sends the rest to me. And I then send in a payment to my lender, with extra rent used to pay down the debt faster.

See how that works? It’s not hard. But it’s something in which you need the right experts in the right places.

My property management company are experts at writing leases, enforcing leases, changing locks with tenants, maintaining the property, doing background checks, and maintaining quality of that process.

But their motivation is to keep the property rented, so they resist raising rents. I recently got notice of a tenant wanting to vacate, and my property manager showed me the proposed rent rate. Within five minutes, I ALSO got an email from my other agent.

Other agent? Who’s that? I have a real estate agent on retainer whose job is to find me new tenants when my properties are available. She gets paid a month of rent for this service, meaning she is motivated to keep the rates up.

Her email tipped me of that the market rent rate of these properties had risen about 12% from what my property manager was doing. This is called “opportunity cost”, something only the right experts in the right places can alert you to.

Other Experts

But this isn’t confined to real estate. There are many areas in life where we should listen to experts. I have seen people slap together “RESTful” interfaces in many places that had nothing to do with REST. For example, I tinkered with the API for my house thermostat, only to discover it was NOTHING like REST.

curl -s -H 'Content-Type: text/json' -H 'Authorization: Bearer ACCESS_TOKEN' '\{"selection":\{"selectionType":"registered","selectionMatch":"","includeRuntime":true\}\}'

This thing barely scratches the surface of an API. There is no hypermedia. The URIs aren’t very “pretty” (which isn’t REALLY a REST thing). It’s more of a query language than anything, which as I’ve said before, isn’t really REST.

My impression after struggling with their API, is that they are experts at building thermostats, not APIs.

Spring Experts

So if you’re seeking to work with a certain technology, a certain business, or other, it pays to go and learn what the most experienced people are doing. It’s part of why I love going to SpringOne Platform every year. I meet people that are ALSO using Spring in incredible detail against some of the largest systems.

It’s an opportunity to see how they have conquered many problems, and an opportunity to share things they may not know, making us all better Spring experts.