Coder, Gamer, Car nut, Foodie, Geek.
3838 stories
·
3 followers

Why Most LED Headlight Upgrades Don't Really Work: An Expert Explains

1 Share

Plug-and-play LED replacements for halogen headlight bulbs are a popular car mod. LEDs often look brighter than incandescent lights, but “looks brighter” and “illuminates better” are not the same thing. I got a stern talking-to from an actual lighting expert about LED retrofits, and science says: Putting LEDs where…

Read more...

Read the whole story
LeMadChef
3 hours ago
reply
Denver, CO
Share this story
Delete

Once Again, Dave Ramsey Is Wrong About Financing A Car

1 Comment

In these uncertain economic times, I can understand turning to “financial experts” for car buying advice, and arguably one of the most famous is Dave Ramsey. Unfortunately, Mr. Ramsey’s insistence on only giving advice in black and white terms can result in information that is both incorrect and unhelpful, especially…

Read more...

Read the whole story
LeMadChef
3 hours ago
reply
TL;DR - just don't listen to Dave Ramsey
Denver, CO
Share this story
Delete

Multi-Layered Ceramics by Artist Heesoo Lee Express the Movements of Land and Sea

1 Share

All images © Heesoo Lee, shared with permission

Heesoo Lee has spent years carefully layering blades of grass, pine trees, and cherry blossoms to construct botanic entanglements that crawl across ceramic mugs and bowls. Inspired by seasonal woodlands and aspen forests, the Montana-based artist recreates bright pockets of landscapes that capture small motions, like falling fronds or rustling branches. “There is movement in trees, but it is slow and subtle, a leaf in wind, the slow growth of new leaves in spring,” she says.

While Lee has continued this tradition with many of her recent pieces, she’s expanded her source material to the ocean. For seven years, the artist lived in Maui, where she often surveyed the water. “I could sit on a beach all day and watch the waves, observe them, and feel calmed by them but also respectful of their energy and force,” she says. The memory has inspired a textured piece that swells upward to form a cavernous bowl. “Even in a small object, the waves are powerful and convey so much. For me, the waves connote freedom, the freedom to express myself and take risks,” the artist writes.

Diverging from land posed new challenges in Lee’s process. For landscapes, the artist repeats elements in layers to create a fully formed piece, but the same technique didn’t translate to water. “The first time I tried to make waves I failed. I failed over and over and over after that. There were cracks, pieces broke off,” she says. “I realized the feeling of making a wave is so much different from making a landscape.” Instead, Lee retrained her hands to follow the movement of the water, using slip casting, carving, and a series of manual techniques to capture its energy and force. Her color palette changed from amalgamations that evoked seasons to a precise set of blues.

Despite her forays into aquatic forms, Lee maintains an affinity for grassy fields and windswept boughs, which she explains:

My seasonal work, landscapes that focus on all four seasons, are still a mainstay of my practice. The memories that fuel the images are so powerful for me, and it gives me great pleasure to share my interpretation of those memories with people… I have heard from people that drinking from a cup I made helped them channel their own memories of the outdoors and the seasons, even during a time when they are stuck inside.

To purchase one of the artist’s organic works, follow her on Instagram, where she often shares shop updates, in addition to early looks into her process.

 

 

View this post on Instagram

 

A post shared by Heesoo Lee (@heesooceramics) on

Read the whole story
LeMadChef
1 day ago
reply
Denver, CO
Share this story
Delete

Just own it, already.

1 Share
Photo: Man wearing “sandwich board” sign that reads “Not all Trump supporters are racist, but all of them decided that racism isn’t a deal-breaker”.
Thanks to Eric Moody for the find!

The post Just own it, already. appeared first on The Adventures of Accordion Guy in the 21st Century.

Read the whole story
LeMadChef
1 day ago
reply
Denver, CO
Share this story
Delete

Being a car enthusiast during COVID-19

1 Share

Under a turbulent, early summer sky a line of Radical RXC GTs trails behind a C8 Corvette pace car appropriately painted Elkhart Lake Blue. There’s a track-wide caution as the parade passes in front of me, slowly lapping around The Carousel. It’s a quiet Saturday morning at the track and I sat back to sip from a thermos of coffee. Minutes later, the distant buzzes of revs rocketed, followed by the immediate slapping of gearshifts. The green flag waved and the chaos resumed.

Road America hasn’t let the threat of COVID-19 put a black flag to racing. Several modifications have been made to ensure spectator safety. Things like posted reminders about practicing “social distancing,” readily available hand sanitizer, and contactless ticket purchasing options. Attending the annual SVRA Spring Vintage Festival (well, scratch that, it was rescheduled from May) proved that it was easy and possible to still be a car enthusiast during this rather bizarre, heavy pandemic. It felt almost reliving being that nearly every other aspect of our day-to-day lives has been uprooted and changed. There, I successfully spent six hours perched at different locations around the sprawling four-mile circuit and never once got within 50 feet of anyone else.

But this isn’t always the case. As local car shows start back up again and smaller oval tracks resume their nightly events, the grandstands become packed and parking lots get crowded. In these circumstances, one simply cannot practice “physical distancing,” the more aptly named term recently coined. While the CDC, WHO, and many of today’s top epidemiologists suggest the risk of COVID-19 transmission is substantially lower when outdoors- we’re quickly learning that doesn’t necessarily hold true in spaces where hundreds of others are congregating, especially when face masks are recklessly, irresponsibly absent.

Is it worth taking a chance? No. Especially since there are still plenty of ways to actively be a car enthusiast in time where it feels like we’re severely limited. That’s where this art of adapting comes into play: Giving up some things we take great joy in doing for the sake of protecting ourselves and our communities.

Yes, I am deeply bummed I’ve already committed to not attending our popular local weekly cruise night this summer. It sucks because for over a decade now this has been my go-to Tuesday routine, but I’d rather not catch a virus that has the potential to isolate myself or my family in the hospital. To suffice, I’ve taken to now committing one evening during my work week to what I happily call “Project car time.” I never would have acknowledged how much of an exodus it feels to commute to my rented $75-per-month storage unit, unlock the door, and dive into hours of wrenching around on my beloved 2001 Chevrolet Camaro.

I’ve migrated most of my tools to this 10 x 20 box, hung a few things up on its walls, and order whatever replacement car parts and essential fluids I need from online vendors rather than walking into the nearest AutoZone. The last strategy has panned out to be much more efficient, cheaper, and shockingly easier than I had expected. With a rechargeable Bluetooth speaker and strong cell reception, I can find whatever helpful YouTube video I need to watch while swapping out a corroded ignition control module or listen to my favorite podcasts and cliche country music.

There’ve been other surprising side effects too of quarantining for months, like realizing how atrocious my coordination is when playing Gran Turismo Sport on PS4 or being able to pay off the remainder of my car loan four years early using the money I’ve saved by not going out or traveling.

All of this for the sake of staying healthy? For me, this honestly hasn’t been that bad of a total alteration.

The post Being a car enthusiast during COVID-19 appeared first on Hooniverse.

Read the whole story
LeMadChef
2 days ago
reply
Denver, CO
Share this story
Delete

Roy Fielding’s Misappropriated REST Dissertation

1 Comment and 2 Shares

RESTful APIs are everywhere. This is funny, because how many people really know what “RESTful” is supposed to mean?

I think most of us can empathize with this Hacker News poster:

I’ve read several articles about REST, even a bit of the original paper. But I still have quite a vague idea about what it is. I’m beginning to think that nobody knows, that it’s simply a very poorly defined concept.

I had planned to write a blog post exploring how REST came to be such a dominant paradigm for communication across the internet. I started my research by reading Roy Fielding’s 2000 dissertation, which introduced REST to the world. After reading Fielding’s dissertation, I realized that the much more interesting story here is how Fielding’s ideas came to be so widely misunderstood.

Many more people know that Fielding’s dissertation is where REST came from than have read the dissertation (fair enough), so misconceptions about what the dissertation actually contains are pervasive.

The biggest of these misconceptions is that the dissertation directly addresses the problem of building APIs. I had always assumed, as I imagine many people do, that REST was intended from the get-go as an architectural model for web APIs built on top of HTTP. I thought perhaps that there had been some chaotic experimental period where people were building APIs on top of HTTP all wrong, and then Fielding came along and presented REST as the sane way to do things. But the timeline doesn’t make sense here: APIs for web services, in the sense that we know them today, weren’t a thing until a few years after Fielding published his dissertation.

Fielding’s dissertation (titled “Architectural Styles and the Design of Network-based Software Architectures”) is not about how to build APIs on top of HTTP but rather about HTTP itself. Fielding contributed to the HTTP/1.0 specification and co-authored the HTTP/1.1 specification, which was published in 1999. He was interested in the architectural lessons that could be drawn from the design of the HTTP protocol; his dissertation presents REST as a distillation of the architectural principles that guided the standardization process for HTTP/1.1. Fielding used these principles to make decisions about which proposals to incorporate into HTTP/1.1. For example, he rejected a proposal to batch requests using new MGET and MHEAD methods because he felt the proposal violated the constraints prescribed by REST, especially the constraint that messages in a REST system should be easy to proxy and cache.1 So HTTP/1.1 was instead designed around persistent connections over which multiple HTTP requests can be sent. (Fielding also felt that cookies are not RESTful because they add state to what should be a stateless system, but their usage was already entrenched.2) REST, for Fielding, was not a guide to building HTTP-based systems but a guide to extending HTTP.

This isn’t to say that Fielding doesn’t think REST could be used to build other systems. It’s just that he assumes these other systems will also be “distributed hypermedia systems.” This is another misconception people have about REST: that it is a general architecture you can use for any kind of networked application. But you could sum up the part of the dissertation where Fielding introduces REST as, essentially, “Listen, we just designed HTTP, so if you also find yourself designing a distributed hypermedia system you should use this cool architecture we worked out called REST to make things easier.” It’s not obvious why Fielding thinks anyone would ever attempt to build such a thing given that the web already exists; perhaps in 2000 it seemed like there was room for more than one distributed hypermedia system in the world. Anyway, Fielding makes clear that REST is intended as a solution for the scalability and consistency problems that arise when trying to connect hypermedia across the internet, not as an architectural model for distributed applications in general.

We remember Fielding’s dissertation now as the dissertation that introduced REST, but really the dissertation is about how much one-size-fits-all software architectures suck, and how you can better pick a software architecture appropriate for your needs. Only a single chapter of the dissertation is devoted to REST itself; much of the word count is spent on a taxonomy of alternative architectural styles3 that one could use for networked applications. Among these is the Pipe-and-Filter (PF) style, inspired by Unix pipes, along with various refinements of the Client-Server style (CS), such as Layered-Client-Server (LCS), Client-Cache-Stateless-Server (C$SS), and Layered-Client-Cache-Stateless-Server (LC$SS). The acronyms get unwieldy but Fielding’s point is that you can mix and match constraints imposed by existing styles to derive new styles. REST gets derived this way and could instead have been called—but for obvious reasons was not—Uniform-Layered-Code-on-Demand-Client-Cache-Stateless-Server (ULCODC$SS). Fielding establishes this taxonomy to emphasize that different constraints are appropriate for different applications and that this last group of constraints were the ones he felt worked best for HTTP.

This is the deep, deep irony of REST’s ubiquity today. REST gets blindly used for all sorts of networked applications now, but Fielding originally offered REST as an illustration of how to derive a software architecture tailored to an individual application’s particular needs.

I struggle to understand how this happened, because Fielding is so explicit about the pitfalls of not letting form follow function. He warns, almost at the very beginning of the dissertation, that “design-by-buzzword is a common occurrence” brought on by a failure to properly appreciate software architecture.4 He picks up this theme again several pages later:

Some architectural styles are often portrayed as “silver bullet” solutions for all forms of software. However, a good designer should select a style that matches the needs of a particular problem being solved.5

REST itself is an especially poor “silver bullet” solution, because, as Fielding later points out, it incorporates trade-offs that may not be appropriate unless you are building a distributed hypermedia application:

REST is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.6

Fielding came up with REST because the web posed a thorny problem of “anarchic scalability,” by which Fielding means the need to connect documents in a performant way across organizational and national boundaries. The constraints that REST imposes were carefully chosen to solve this anarchic scalability problem. Web service APIs that are public-facing have to deal with a similar problem, so one can see why REST is relevant there. Yet today it would not be at all surprising to find that an engineering team has built a backend using REST even though the backend only talks to clients that the engineering team has full control over. We have all become the architect in this Monty Python sketch, who designs an apartment building in the style of a slaughterhouse because slaughterhouses are the only thing he has experience building. (Fielding uses a line from this sketch as an epigraph for his dissertation: “Excuse me… did you say ‘knives’?”)

So, given that Fielding’s dissertation was all about avoiding silver bullet software architectures, how did REST become a de facto standard for web services of every kind?

My theory is that, in the mid-2000s, the people who were sick of SOAP and wanted to do something else needed their own four-letter acronym.

I’m only half-joking here. SOAP, or the Simple Object Access Protocol, is a verbose and complicated protocol that you cannot use without first understanding a bunch of interrelated XML specifications. Early web services offered APIs based on SOAP, but, as more and more APIs started being offered in the mid-2000s, software developers burned by SOAP’s complexity migrated away en masse.

Among this crowd, SOAP inspired contempt. Ruby-on-Rails dropped SOAP support in 2007, leading to this emblematic comment from Rails creator David Heinemeier Hansson: “We feel that SOAP is overly complicated. It’s been taken over by the enterprise people, and when that happens, usually nothing good comes of it.”7 The “enterprise people” wanted everything to be formally specified, but the get-shit-done crowd saw that as a waste of time.

If the get-shit-done crowd wasn’t going to use SOAP, they still needed some standard way of doing things. Since everyone was using HTTP, and since everyone would keep using HTTP at least as a transport layer because of all the proxying and caching support, the simplest possible thing to do was just rely on HTTP’s existing semantics. So that’s what they did. They could have called their approach Fuck It, Overload HTTP (FIOH), and that would have been an accurate name, as anyone who has ever tried to decide what HTTP status code to return for a business logic error can attest. But that would have seemed recklessly blasé next to all the formal specification work that went into SOAP.

Luckily, there was this dissertation out there, written by a co-author of the HTTP/1.1 specification, that had something vaguely to do with extending HTTP and could offer FIOH a veneer of academic respectability. So REST was appropriated to give cover for what was really just FIOH.

I’m not saying that this is exactly how things happened, or that there was an actual conspiracy among irreverent startup types to misappropriate REST, but this story helps me understand how REST became a model for web service APIs when Fielding’s dissertation isn’t about web service APIs at all. Adopting REST’s constraints makes some sense, especially for public-facing APIs that do cross organizational boundaries and thus benefit from REST’s “uniform interface.” That link must have been the kernel of why REST first got mentioned in connection with building APIs on the web. But imagining a separate approach called “FIOH,” that borrowed the “REST” name partly just for marketing reasons, helps me account for the many disparities between what today we know as RESTful APIs and the REST architectural style that Fielding originally described.

REST purists often complain, for example, that so-called REST APIs aren’t actually REST APIs because they do not use Hypermedia as The Engine of Application State (HATEOAS). Fielding himself has made this criticism. According to him, a real REST API is supposed to allow you to navigate all its endpoints from a base endpoint by following links. If you think that people are actually out there trying to build REST APIs, then this is a glaring omission—HATEOAS really is fundamental to Fielding’s original conception of REST, especially considering that the “state transfer” in “Representational State Transfer” refers to navigating a state machine using hyperlinks between resources (and not, as many people seem to believe, to transferring resource state over the wire).8 But if you imagine that everyone is just building FIOH APIs and advertising them, with a nudge and a wink, as REST APIs, or slightly more honestly as “RESTful” APIs, then of course HATEOAS is unimportant.

Similarly, you might be surprised to know that there is nothing in Fielding’s dissertation about which HTTP verb should map to which CRUD action, even though software developers like to argue endlessly about whether using PUT or PATCH to update a resource is more RESTful. Having a standard mapping of HTTP verbs to CRUD actions is a useful thing, but this standard mapping is part of FIOH and not part of REST.

This is why, rather than saying that nobody understands REST, we should just think of the term “REST” as having been misappropriated. The modern notion of a REST API has historical links to Fielding’s REST architecture, but really the two things are separate. The historical link is good to keep in mind as a guide for when to build a RESTful API. Does your API cross organizational and national boundaries the same way that HTTP needs to? Then building a RESTful API with a predictable, uniform interface might be the right approach. If not, it’s good to remember that Fielding favored having form follow function. Maybe something like GraphQL or even just JSON-RPC would be a better fit for what you are trying to accomplish.

If you enjoyed this post, more like it come out every four weeks! Follow @TwoBitHistory on Twitter or subscribe to the RSS feed to make sure you know when a new post is out.

Previously on TwoBitHistory…

  1. Roy Fielding. “Architectural Styles and the Design of Network-based Software Architectures,” 128. 2000. University of California, Irvine, PhD Dissertation, accessed June 28, 2020, https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation_2up.pdf

  2. Fielding, 130. 

  3. Fielding distinguishes between software architectures and software architecture “styles.” REST is an architectural style that has an instantiation in the architecture of HTTP. 

  4. Fielding, 2. 

  5. Fielding, 15. 

  6. Fielding, 82. 

  7. Paul Krill. “Ruby on Rails 2.0 released for Web Apps,” InfoWorld. Dec 7, 2007, accessed June 28, 2020, https://www.infoworld.com/article/2648925/ruby-on-rails-2-0-released-for-web-apps.html 

  8. Fielding, 109. 

Read the whole story
LeMadChef
2 days ago
reply
Denver, CO
Share this story
Delete
1 public comment
emdeesee
13 days ago
reply
I mean, yeah, alphabet soup, but kind of interesting alphabet soup.
Sherman, TX
Next Page of Stories