diff --git a/content/public/web-development/content.md b/content/public/web-development/content.md index 3638d0bf..d329081d 100644 --- a/content/public/web-development/content.md +++ b/content/public/web-development/content.md @@ -9,7 +9,7 @@ dateblock: {!!dateblock!!} -I differentiate [software development](/software-development) from web development in the sense that all web development is software development but not all software development is web development. Web development is software development in a specific context, with contextual constraints. +I differentiate [software development](/software-development) from web development in the sense that all web development is software development but not all software development is web development. Web development is software development in a specific context, with contextual [constraints](/web-development/on-constraints). Generally speaking, when I do develop software, I do it for the web. Further, I take a user down approach. (I never reach, "the metal".) However, after poking around and looking I can say that, at a reasonable level of abstraction, developing software feels the same. @@ -33,78 +33,4 @@ You can read more about the 2021 update [over here](/web-development/2021-site-i November 5th update: I just realized [JAMstack](https://jamstack.com) was a thing and I find it funny from the perspective that it's kinda where we're heading. Pretty sure this was originally the idea, precursor, or concept around server-less, which I admittedly didn't pay too much attention to. I'm listening to an audiobook on the subject right now and they seem to be making some of the same arguments and points I've been making and brain-dumping here. -## And before - -This is the brain-dump history. You've been warned. (All the years are rough.) - -### 2019–2020 - -The site at that time focused on productivity coaching. And had two design iterations in that time. I've never viewed a website as being necessary to operate professionally in this world. Contrary to what it may feel like, most people on this planet don't have a website and don't participate in social media. - -Some are too young. Some don't have access to the technology and infrastructure. And others simply can't be bothered. - -While I had been using [Laravel](https://laravel.com) I started feeling weird about it. I wanted to be decoupled from everything. I wrote a wrapper for [.PHP](PHP: Hypertext preprocessor) itself; that's how decoupled I wanted to be. Now, I can say I'm pretty well decoupled from most of the little things. - -If my host goes out of business tomorrow, I can move the files somewhere else without much issue. Granted my host has been my host for roughly 15 years at this point. - -I use Git for source control and the site and content are stored on GitHub. So, I have local copies and if GitHub dies, I'll be able to move the code somewhere else. - -Basically, I have catastrophic failure covered and, as of this writing, this website doesn't help feed me, so, if it goes down I probably wouldn't notice and neither would most of the planet. That's not a knock or self-deprecating humor, that's just the facts at hand. - -I started thinking about micro-objects and the proxy and facade pattern as a way of decoupling myself from dependencies. I used service providers exclusively when developing with Laravel because I could put all my code there and leave all the Laravel code "over there." Then I realized my controllers didn't *need* to inherit from the Laravel base controller. I also started pealing back more and more of the "how are they doing this" layers to realize just how little of Laravel I was using for most of my work. - -Stopped using databases in favor of markdown and front matter; so, not using Laravel database migrations or [Eloquent](https://laravel.com/docs/8.x/eloquent). Was using the [CommonMark](https://commonmark.thephpleague.com) package from the league of extraordinary packages for most of the HTML and have my own libraries for the rest; therefore, not using Laravel [Blade](https://laravel.com/docs/8.x/blade). Opted out of creating admin panels—just use source control services or an [.FTP](file transfer protocol) client; so, no [authentication layer](https://laravel.com/docs/8.x/authentication) needed. And I don't take payments online from a diverse audience, so, no need to integrate with multiple payment providers using something like [Cashier](https://laravel.com/docs/8.x/billing) and I don't really have the inclination to write the integration; 8fold is using Wave's invoicing mechanism and I'm happy to pay the few cents each time a transaction is made. I was barely even using the router; had three routes and they accepted *any* [.URL](uniform resource locator) and the controller processes that path. - -Now, could I find excuses to *need* all that stuff? Absolutely. - -As someone who enjoys solving their own problems and building stuff online is it hard to stop myself from doing it for its own sake? You (probably) have no idea. - -Am I happy that my ability to upgrade my code is less dependent on other people? One hundred percent. - -Still recommend Laravel to anyone. Hands down. With that said, I went back to my roots on this one: - -> If you aren't going to use half of the things provided by a library or framework, you better have a damn good reason for taking it on. - -### 2018 - -(By the way, I'm totally cheating. I'm too much of a time lord to actually remember any of these dates. But the [Wayback Machine](https://web.archive.org/web/20180330105911/https://joshbruce.com/) is pretty awesome.) - -This was one of those odd moments when I thought I wanted to embrace my software developer moniker. I believe I had also become recently unemployed and threw a site together real quick. Looks like I used a modified [.USWDS](United States Web Design System). - -### 2010–2017 - -I actually didn't own the joshbruce.com domain until 2010. And I didn't do much with it for this seven year span of time. - -During this time I spent more time trying out other people's platforms than working on my own. Embracing that Web 2.0 consumer-created content life, I suppose. - -I always had concerns regarding using other people's platforms. The main concern being that I didn't own the terms of service or the business operations. So, I never knew what would happen next. - -Would the company decide to do some interesting things with paywalls once they became popular enough to start being exclusionary in their practices, for example? - -Not that it every happened, of course. (Totally happened. Or at least felt like it from my perspective.) - -Based on my socisl media posts, I'm pretty sure I started using Laravel during this time. I appreciated Laravel a great deal. Think I even mentioned once that it felt like what my initial attempts could have turned into. In other words, it felt natural to me to use. Intuitive. However, I also acknowledge that while that may be the case for me, it's most likely not the case for everyone. - -### 2007–2009 - -We could probably call this the Dark Ages for me. - -I took my site down. I wasn't really on other platforms much. - -And yet, I was freelancing full-time as a web developer and business consultant. - -One exchange I'm fond of reflecting on was asking a client: Why do you think you need a website? - -The response was pretty typical: everyone needs a website these days, it projects legitimacy, and similar. - -My response was: You're about to hire a web developer who doesn't have a website. How did that happen? I'm willing to take your money to make the site, don't get me wrong, I need to eat; it's not what I recommend you do though. Your money would be better spent on branded t-shirts and giving them away to local shelters and doing more community outreach like that. You're a local brick-and-mortar. Selling things online is a long ways off for you. Pay me a few hundred dollars for this advice and take the other thousands of dollars and do the community outreach bit. - -They paid for the site. - -### Prior - -Pre-college. Had some client work. And had a standard issue blog, like most internet people at the time. I developed my own CMS and was using that. It wasn't horrible for the time. - -Of course, I found an iteration of the code I found somewhere and thought: Cool! I could totally use this as the foundation for my next website iteration. - -Then I opened the authentication code. And closed the file faster than someone closing the closet door when stuff starts falling off the top shelf. Reminding myself once again to always be humble. +[My history on the Internet](/web-development/my-history-on-the-internet) started in 1998 and has never been able to truly hold my attention. I feel like once I hit a certain level of mastery, I'm kinda bored of it. It takes a lot for me to keep practicing in the plateau. With that said, I've never really wanted to be a software developer or engineer; I just like building things and projects like this site help me communicate to teams what's going on in my head and what I'm seeing in the outside world. diff --git a/content/public/web-development/modern-web-development/content.md b/content/public/web-development/modern-web-development/content.md index 165f63e1..225acffb 100644 --- a/content/public/web-development/modern-web-development/content.md +++ b/content/public/web-development/modern-web-development/content.md @@ -77,155 +77,5 @@ The promise from an HTML-perspective was [semantic markup](https://www.w3.org/st I first heard about [microdata](https://html.spec.whatwg.org/multipage/microdata.html#microdata) and microdata vocabularies around 2009. This let you put attributes in your HTML elements to help further describe the content. For example, if you view the source of this page, you should see that the article tag uses a `typeof` attribute with a value of `BlogPosting` and a `vocab` attribute with a value of `https://schema.org`. This means I'm using the microdata vocabulary from [schema.org](https://schema.org/) and a computer reading this file can better understand my intent; as long as it can read [.XML](eXtensible Markup Language) (specifically HTML) and can understand the schema.org vocabulary. The navigation is wrapped in a `nav` element, describing the intent of that area of the page. This article is wrapped in an `article` element, defining the intent. The microdata further describes my intent. I could put the microdata at the top of the page using [.JSON-LD](JavaScript Object Notation for Linking Data); however, I would prefer to put it in the HTML itself because the interpreter doesn't need to know [.JS](JavaScript) to interpret the intent, thereby, being technologically agnostic—anything that can parse XML (or a plain text string) can interpret this page. -## 1998 +[My history on the Internet](/web-development/my-history-on-the-internet) has been interesting. -I used a free [.WYSIWYG](what you see is what you get) editor provided by my [.ISP](internet service provider) to create a website. - -Think of this like Wix or similar. - -Tools like these made the Internet feel accessible. Anyone could easily create content and put it somewhere. Not only that but people using assistive technologies could experience the same thing; it’s pretty difficult to make an inaccessible website. - -## 2000–2004 - -Bought my first domain name and got a “real” host. - -Speaking of making sites inaccessible, I started developing sites using Flash. I appreciated it, for the most part, the site was the same regardless of browser. I was really hung up on the “pixel perfect” thing and with the browser wars going on it seemed impossible. - -Flash was my first introduction into a front controller, or single-page app. - -You delivered a single page and loaded a multi-faceted experience. No page refreshes. No delays between requests. Often broke the back button and caching was a problem more than a solution. - -Think of it like Angular a decade before Angular. - -What sucked about Flash was you had to load the entire site at once and there was only the one route to share with someone. If I wanted you to see a specific portion of a site, I had to tell you how to navigate there and you’d have to wait for the entire site to be downloaded even if you were only going to a small sub-area. And heaven forbid the creator changed the navigation before you got there. - -Eventually things advanced to the point we could request images, text, and other files when we needed them instead of it all being part of the initial download. We were also able to use JS to update the routes using [fragments](https://en.m.wikipedia.org/wiki/URI_fragment) (hash). Now I could keep my assets on the server and “make calls” to retrieve them when needed; think of this like a web [.API](Application Program Interface) call in "modern" terms. Further, you could send me `http://yourdomain.com/#about`, load a minimal experience to let me know something’s happening grab the route and determine which view I was supposed to see. - -Again, think Angular and similar single-page client-side web app solutions as they were up until around 2015. Or Gmail as of October 2021: - -``` -https://mail.google.com/mail/u/1/#inbox -``` - -Of course, Gmail isn’t Flash, it’s JS. - -## 2005–2007 - -I created my last Flash site in this time. It was the most “modern” iteration I made. The initial download was around three kilobytes. From there you could view almost 100 pieces of artwork in my portfolio along with my résumé. - -During this time the prevalence and popularity of the single-page server-side web app also seemed to be taking hold. Our routes turned into a jumbled mess made for computers: - -``` -http://yourdomain.com/?p=123&q=hello -``` - -The idea of a “front controller” is basically telling the server, “No matter the route, use this single file instead. I’ll figure it out.” Basically we, as developers, are taking on the burden of the server without becoming server administrators. - -[WordPress](https://wordpress.org) coupled with [Apache](https://httpd.apache.org) was the first combination I saw with "pretty Permalinks." Which is to say, developers were able to write their `index` files in a way that allowed them to build a coherent response from a human-readable route. - -I learned how the front controller worked (`.htaccess` files) and this approach along with the idea that the route was the keystone became the foundation of the first [.CMS](content management system) I ever built. - -Complaints and concerns about Flash were also on the rise. Meanwhile browsers were less finicky than they had been in the past as we pushed for simple, semantic markup. I was also a follower of those who were pushing the importance of accessibility and speedy delivery of content. - -In 2007, I took my sites down. - -## 2007–2010 - -During this time I worked full-time as a freelance web developer. - -For me, this was the Dark Ages. I started freelancing as a web developer and removed most, if not all, of my content from my personal sites. I barely used the newly coined "social media" platforms. My favorite conversation with my small business clients usually started with the question: - -> Why do you think you need a website? - -They would give me reasons, which usually boiled down to, it legitimizes you as a business. To which my response was usually: - -> You're about to hire me to do this work. I don't have a website. How does that fit into your rationale for needing a website; especially given you are small, local, brick-and-mortar shop. - -During this time it was about being discoverable and being on social media platforms. Some websites I had visited regularly changed to a single page with links to various social media platforms. - -[[.AJAX](Asynchronous JavaScript and XML)](https://en.wikipedia.org/wiki/Ajax_(programming)) (first seen in 1999) started becoming more prevalent as a concept for interactivity on the Internet. A user clicks something, but instead of moving to a different page, a sub-request is sent to the server and a response is delivered. JS is then used to interpret the response and update the HTML. - -"Modernizing" websites was about taking static sites and converting them to database-driven, dynamic sites that users could "update themselves." We called them dynamic because the content of the page could change without modifying the code running the application or individual HTML files. - -This was also the time that I started developing my view of how the Internet works and the adoption curve. - -There is only so much we can do with the native elements of HTML and CSS; so, we use non-core elements to push the possibilities. Eventually, many of those possibilities become part of the core elements for the web. When that happens, it's our responsibility to deprecate those former solutions in favor of the new standards as much as is practical given our constraints. This is what it is to modernize. However, if the drive is to always be "modern" then you can often find yourself in a bad position as evolution may not select your version of "modern" for the future (see Flash in 2010). - -This was the time of JS libraries like jQuery, which simplified the development of client-side interactive elements. However, because it only manipulated the attributes of HTML elements, the performance often left something to be desired. - -Bandwidth was still an issue in the [.US](United States) and the concept of lazy-loaded assets became somewhat popular. Is that image below "the fold"? Then don't load it yet, we'll do that later by calling the server ourselves. (Again, taking more responsibilities from the browser and server and putting it more on our own code.) - -The barrier to entry of creating content online for the world to see was lowering. With minimal cost or for the cost of personal information and looking at ads amongst the content, just about anyone could create content online for public consumption. - -HTML and CSS specifications started gaining more ground and becoming more formalized. This was the time of the [second browser war](https://en.wikipedia.org/wiki/Browser_wars). The dominate browser at the time was [.IE6](Internet Explorer version six) and it was so horrible at being compliant with the specifications that it earned the nickname Internet Exploder, because its use caused the internet to explode despite the page being otherwise perfect from a specification perspective. Apple (via [Steve Jobs](https://en.wikipedia.org/wiki/Thoughts_on_Flash)) turned its sights on killing Flash. - -Some of the web development sites I frequented would display banners urging you to use a different browser for the best experience because the designer, developer, or both would no longer make the time to account for IE6, [IE6 must die](http://www.ie6death.com). - -JS was picking up even more steam and for good reason. With the trifecta of the web: HTML, CSS, and JS. I can make a fully interactive and dynamic website with no more tooling than a browser and a plain text editor. - -No server. No domain name. No host. No database. - -Seriously, if you want to "do web development" you can crack open Notepad (Windows) or TextEdit (macOS) and get started; both come pre-installed on both operating systems. Granted, that's always been the case. - -When I worked at a call center I used to develop HTML layouts between and sometimes during calls. I worked there from 2001–2007. - -## 2010–2013 - -The idea of breaking a page or experience into fragments and loading them through delayed server requests really started taking off. - -"Modernizing" started to mean moving to [microservices](https://www.martinfowler.com/microservices/) and single-page client-side web apps to solve the "Does it scale?" problem. - -Server-side solutions and languages felt like they had fallen into disrepair, were slow, and had gotten a bad rap; despite WordPress still being the dominate survivor of the CMS wars. One of my favorite compliments around this time (actually 2015) was that my PHP code wasn't like any other PHP code the developer had seen because "I can read it." (Granted, if they had seen my code from 2007–2010, they might have felt different.) - -I worked full-time for a year as a front-end web developer. We mainly did brochure sites. Some sites required so much customization of WordPress I found myself beating WordPress into submission as much as I could to make it easy, then writing instruction manuals on how the clients could update the content themselves. - -During this time native app development started to increase with the opening of the App Store to more developers. I started learning Objective-C and developed an app for iOS. - -Of the two, I appreciated native app development the most, specifically for the Apple ecosystem. - -There was also the beginnings of a "back to basics" movement for web development with the creation of "modern" static site generators (similar to FrontPage and Dreamweaver from years prior, only with an automated build step). These static site generators work like dynamic sites, but convert the pages to static HTML instead of using processing time to dynamically generate (render) the page. - -## 2013–2016 - -During this time it seemed like everyone I talked to about web development was looking toward what they considered the bleeding edge of modern. - -Modernizing "legacy" websites became a more dominate industry unto itself. Creating new sites also required this "modern" means of development. - -I remember going to a locally owned restaurant website. I watched as the site instantly loaded a blank field of color, then the spinner-of-doom appeared to let me know I would need to wait while the API calls were made and the content returned (basically doing the first round trip a second time). It was a single page and displayed the menu for the restaurant. The design was lackluster and not complex at all. My cynical side said, "They spent all their budget on 'future-proofing' a site I could have coded in a day." - -I started working on another program as a "professional" consultant. They too were looking to do "modern" web development after being sued for their site not being accessible. We talked about APIs and micro services. Angular was just going from version one to two. Teams wanted to be able to use whatever technology they wanted to in order to deliver what was asked of them; regardless of how difficult it would be to maintain and find the people with the necessary skills to do so. - -In one case in particular we needed a form that someone would submit, it would be reviewed, and then approved for publication. The proposed solution was to integrate with GitHub and use their APIs and document review workflow. All this despite the infrastructure being in place to do this "the old-fashioned way" in less than a week. - -I learned and grew a lot during this time. I still remember looking at the Product Owner and saying, "I'm just gonna build it." When he asked me what I meant, I said, "I'm going to build what we've spent the last two months asking them to build." He asked how long it wold take, to which I responded, "I'll have however much I can have in two weeks or less." - -I made contributions to a couple of open source projects, one of which was a design system being developed by the same organization. I used that to define HTML patterns and CSS. I used the framework I was just learning to start the application work. Put a database schema together and had a working prototype in two weeks that could also demonstrate the flexibility of front-end development. - -We set a meeting with the other Product Owners. I made more progress on the system and practiced the demo. We demoed it. The program turned upside a bit and we started making real progress. - -## 2016–2020 - -I remember working alongside one of the developers on the aforementioned program. We would have philosophical debates about web development. Eventually he said he had come to appreciate and understand the benefits of progressive enhancement. (I'm not sure how much [this article](/web-development/on-constraints/internet-bandwidth/) had to do with that decision.) - -The idea of the internet innovation curve came on stronger during this time and we would discuss ways to push what was possible, including pushing for progress in browser support for various features. - -## 2021– - -There seems to be a renaissance of the server-side application. The monolithic application even. More and more businesses and developers seem to be appreciating that not all websites need to leverage APIs and extensive JS. - -Meanwhile some organizations and businesses are just starting their microservice and single-page client-side web app journey. - -Which of these is on the bleeding edge and which is behind the curve? - -Or, maybe, they're both fine. The question I have is: Are you *choosing* the approach that best suits your needs, context, and constraints? If your company went all [.GM](General Motors) tomorrow, could you maintain your website? - -Let us also consider the notion of low- and no-code solutions, which were also available and promised in 2001. "Develop a full blown website without learning how to write code!" - -What does "modern" mean again? - -The codebase for this site as of this writing, would be considered a monolith. With that said, this monolith can deliver this site using: - -- dynamic page building and -- a static site. - -Would we be better served if this was *not* a monolithic app? diff --git a/content/public/web-development/my-history-on-the-web/content.md b/content/public/web-development/my-history-on-the-web/content.md new file mode 100644 index 00000000..8c99d810 --- /dev/null +++ b/content/public/web-development/my-history-on-the-web/content.md @@ -0,0 +1,341 @@ +--- +title: My history on the web +dateblock: + - 20211108 Created on +--- + +# My history on the web + +{!!dateblock!!} + +I found myself telling the story of me and my participation online in multiple places; decided it would be easier to just put it all in one place. The following is in reverse chronological order and the years are rough. Further, it's important to note that there is a difference between when something started and when *I* became aware of and started using something. + +## 2021– + +There seems to be a renaissance of the server-side application. The monolithic application even. More and more businesses and developers seem to be appreciating that not all websites need to leverage APIs and extensive JS. + +Meanwhile some organizations and businesses are just starting their microservice and single-page client-side web app journey. + +Which of these is on the bleeding edge and which is behind the curve? + +Or, maybe, they're both fine. The question I have is: Are you *choosing* the approach that best suits your needs, context, and constraints? If your company went all [.GM](General Motors) tomorrow, could you maintain your website? + +Let us also consider the notion of low- and no-code solutions, which were also available and promised in 2001. "Develop a full blown website without learning how to write code!" + +What does "modern" mean again? + +The codebase for this site as of this writing, would be considered a monolith. With that said, this monolith can deliver this site using: + +- dynamic page building and +- a static site. + +Would we be better served if this was *not* a monolithic app? + +## 2017–2020 + +Key takeaways: + +1. Interacting with databases takes a lot of code. +2. Creating the administration panel of a website takes a lot of code. +3. Solid state drives are wicked fast. + +Was laid off for the third time. Modified the website to showcase my development work, open source projects, and products; not sure why, but that's what I did. + +Wrote a book. + +Changed the site again to be a bit more focused on coaching individuals and small businesses. + +Mom passed away and I took some time before starting my next position. + +## 2017 + +Key takeaways: + +1. Use the fringes to to advance adoption and improve the core. +2. Adoption on the Internet is slow. +3. Chasing the new hotness is exhausting. + +The last year I was on the program from 2013–2016 I remember working alongside a developer; it was a wonderful experience and I grew a lot. We would get into debates and arguments about web development. + +Initially he was pretty much all-in on the single-page, client-side web app approach. As we talked he started to shift though. Testing became a focus and he really appreciated the idea of progressive enhancement. I was channeling my frustration into creating the on constraints series and I don't know how much the one on [internet bandwidth](/web-development/on-constraints/internet-bandwidth/) got him thinking about progressive enhancement and the idea of how the Internet evolves, but it was after sending him that one that he basically altered his approach. + +The idea is evolution in general. + +We are all bound by the technologies of our times. The stuff at a thing's core get iterated on, experimented upon, and eventually they calm down. It's amazing that you can open a plain text editor (turn rich text formatting off), write some text, and save the file with a `.html` extension and display that in a browser. You just created a website. + +Of course, if you want to do something "interesting" with it you'll need to add some styling—you can do that inline by adding attributes to an element, a style tag in the head of the document, or by creating another plain-text file…no special tools or applications required. + +Or course, if you want to do something "interesting" you'll want to do some interactive things, which can be done with another plain-text file and either JavaScript or [.CSS](Cascading Style Sheets). + +No special tools or build steps required. + +I think this is part of why the explosion recently has been more about serverless and client-side approaches, they can all be built without any special skills, knowledge, or tools. + +We keep making it easier and easier to do what used to take special skills, knowledge, and tools by bringing it into the core of the technologies. Calling APIs with JavaScript used to be pretty difficult in comparison; now, not so much. + +It's like pruning a tree. + +We spend time growing into the space beyond the trunk. We create tools like jQuery, Angular, React, Laravel, WordPress, Drupal, Bourbon, Sass to push the boundaries; to grow beyond the box and constraints. And, eventually, some of the things that used to be difficult to near impossible become truly native to the core of the platform. + +[Client-side form](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) validation and [accordions](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details) to name but two. And, eventually, we'll get the [modal](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog) we all deserve. My contention is that we have to start using them now though to press implementation by the browser developers. We use the markup in our sites and maybe use polyfills to help provide cross-browser support and, when the browsers catch up, we can get rid of the polyfill; again, [for the modal](https://github.com/GoogleChrome/dialog-polyfill) we all deserve, for example. + +## 2013–2016 + +Key takeaways: + +1. Humans like solving complex problems. +2. If the problems aren't complex, we will tend to complicate the solution anyway. +3. Beginning with the end in mind isn't the same as trying to begin at the end. + +Static sites. Serverless. Back to the monolith—just make sure it's modular. + +It felt like we had started learning about the drawbacks to the uptick in microservices; they don't solve the complexity, they shift it. I started watching talks by those who had been in the software development industry much longer than me. + +Everyone was talking about using the right tool for the job; only no one could agree on what the right tool was. + +I went to a locally-owned restaurant's website. It consisted of a single page with location, hours, contact information, and the menu; it was reminiscent of the site I made in 2001. The initial load was instant, but then I had to wait as the single-page, client-side web app code spun up and requested the data it didn't get from the server the first time. + +A project I was on as UX[.UX](User Experience) expert I remember my team waiting for two months for the following requirements to be demonstrated: + +1. A form with 7 fields. +2. The data would be stored somewhere. +3. It would need to be reviewed somehow before being published. + +The proposed solution was going to incorporate GitHub and use the APIs to perform the review process. I explained that it seemed like a pretty complex solution for something so simple that we've been doing on the Internet since the early 2000s; can we break it down into something simpler and build on that? + +That didn't go over well. + +Out of frustration in waiting and trying to get the non-technical among us to understand my frustration I told the product owner: I'm just gonna build it. + +He asked what I meant. I said I was going to build in two weeks what we've been waiting two months for them to build. I cracked open [Laravel](https://laravel.com) and went to town. I built atomic, reusable components and contributed to the [United States Web Design System](https://designsystem.digital.gov). In two weeks I demonstrated what I had. The product owner said, "We need to show to everyone else." A week, and a few improvements later, we did. + +This was the first time I had heard the phrase: Front-end development just takes so long. + +I was floored. I couldn't understand. Then I saw how the tools that were being used worked; it all made sense. What I could do and change in a matter of seconds would take forever using "modern" tools. + +The program shifting dramatically after the demonstration. We started building our own design system for the program, using the research and groundwork from the [.USWDS](United States Design System). We started making a component library for reusable components to be shared across multiple development teams on the program. While the USWDS used a modified [[.BEM](Block Element Modifier)](http://getbem.com/introduction/) approach, one of our front-end developers wanted to use a more utility-based approach; inspired by a seemingly dead or dying project [Semantic UI](https://semantic-ui.com/?ref=framestack). + +## 2012–2013 + +Key takeaways: + +1. Establish boundaries early in relationships and stick to them. +2. If you're good at something, it's easy for people to forget the pain that got them the result. +3. It's not the speed increases; it's that complexity of future work decreases while the changeability of the system overall increases. + +After getting laid off I worked as a web developer "for corporate." Mainly brochure and marketing sites. Parallax scrolling became a thing for a while, one of our sites used it and I did the math to make it work. I created my first single-page, client-side web app completely in JavaScript using [.API](Application Program Interface) calls. + +I worked 6 weeks at 72 hours a week and was pushed to do more and to "go faster." + +(Years later I created [a talk](https://youtu.be/jeX4fan9xHI) using the experience as the reference.) + +I had started looking into developing native apps for iOS in the past two years. During this time, I released an app written in Objective-C. I wasn't a web designer or developer, I just liked making things. + +Dynamic site generation was waning. There was an evolution of static site generators and frameworks for building single-page, client-side web apps. For the former there was [Jekyll](https://jekyllrb.com); initial release, 2008.For the latter there was [Sproutcore](https://sproutcore.com/about/) and later Angular and React. Now we had an approach for the primary types of applications people were developing. Content-based experiences, app-like experiences, and the content (data) management and administration experience. + +Each with its pros and cons. + +It felt like everyone started realizing what Apple had been up to and jumped on that train. ([Grid Style Sheets](https://gss.github.io), for example.) + +Two out of the three mentioned projects now seem to be dead or dying. + +## 2011 + +Key takeaway: There's no such thing as permanent employment. + +The idea of performing network calls to update a page without refreshing was picking up steam; [.AJAX](Asynchronous JavaScript and eXtensible Markup Language) hade been around since 1999 and this felt like a further evolution of those concepts. + +Things we got for free from the server, the browser, or both started being taken on by frameworks and developers. Server-side languages started feeling like they had fallen out of favor and into disrepair. The CMS wars seemed to had run their course as it was no longer about getting people to have their own website and turned into helping people become content creators and influencers on everyone else's platforms. + +This is also when I was formally introduced to Agile Software Development. I was brought onto a project as a UX Expert. When I walked into the room, the technical lead said: We do Scrum here. + +When asked what that was he explained it in that way people explain things that they know enough to be dangerous but maybe feel like they're lacking the nuance; it felt familiar. It sounded like what I had spent the last three years doing. + +I ran home and found as many things as I could find on the subject. It seemed like I found where I would naturally fit in. + +The project was built on Microsoft technologies, which was fine, all I cared about was that I was a UX expert on the project. I worked with designers to improve the presentation. I worked with developers to improve their code and their approach. + +I got laid off for the first time in my life. + +## 2010 + +Key takeaways: + +1. Flow is a powerful force. +2. Minimizing dependency creates flexibility. +3. Content creators don't really *want* to update their own sites. + +Living in my car. It was one of the best years of my life. I would still do development work on occasion. Not having to pay rent or utilities was a blessed relief. Avoiding telling people because I feared they would try and help me to the point of hurting me was a curse. + +I worked on the United States Census that year. I did well. My team did better. My performance kept me on for three operations in a row. But, I didn't have an exit strategy and the last operation required a phone line to direct connect to the Census to redistribute work to other workers with laptops. Modifying the flow of work became a huge bottleneck and I didn't see a way around it. + +I got a call from a recruiter for the first time. It was for a 6 month contract at WebMD as a content publisher. It paid almost double what I had ever made in my life. My job was to copy and paste from relatively plain text documents into the forms of their custom [.CMS](Content Management System). That was it. I would go in. There would be a bunch of word processing documents assigned to me. I would select the template, copy-and-paste into the form, and submit the content for review. + +Again, I was getting paid double what I was accustomed to making and almost three times what I had made my last year of full-time freelancing. + +## 2007–2010 + +Key takeaways: + +1. Releasing a little bit on a regular basis is the shortest way to get managers to stop asking for status. +2. Never enter anything without an exit strategy. +3. Accessibility and semantics are important. + +We'll call this The Dark Ages. + +I took my sites down and just started squatting. I didn't want to do development; not sure what I *wanted* to do if we're being honest and in the decade of having a site I only received the one gig from it, and didn't get paid for it. This colored my perception quite a bit when talking with potential clients. One exchange in particular has always stuck with me: + +> Why do you think you need a website? + +They would give me reasons, which usually boiled down to, it legitimizes you as a business. To which my response was usually: + +> You're about to hire me to do this work. I don't have a website. How does that fit into your rationale for needing a website; especially given you are small, local, brick-and-mortar shop. + +Publishing platforms like Twitter, MySpace (waning), and Facebook were starting to take off as a way for folks to create content online. The owner of the boutique marketing firm I mentioned showed me a corporate website one day. + +It was a single page. It had about 100 words of copy. Then it had a bunch of links to their presences on various other platforms. The boutique owner simply said: + +> They get it. + +I think he was right for the time. + +Modernizing a website in this time was in converting static files into content stored in a database and templates to display pages. People wanted sites they could update themselves. + +This is the time when I jokingly say I "invented" [Agile Software Development](https://agilemanifesto.org). + +My biggest client was a department at a university. They were modernizing their site. I developed the CMS for the site, wrote the data migration scripts, pretty much everything. + +One day I asked if I could speak to the customer because going through the project manager was starting to wear thing. The project manager had apparently never been asked that question before, but said he would ask. When I got on the phone with the customer I said: + +> Listen, you're sending me these emails. Some are bug reports. Others are feature requests. It's difficult to keep it straight and obviously things are falling through the cracks and annoying both of us. So, I would like to propose something. + +1. I will keep a list (backlog) of all these requests. +2. On Monday we'll get together and prioritize those items and make sure I understand them and aren't missing any to the best of our knowledge. +3. On Friday we'll get together again and I'll show you what I believe I can mark as done and you can verify that I they are done. Further, on this day, send me *one* email with all the new stuff to add to the list. +4. In between those two days, I won't reach out to you unless it's impacting the current work, and you won't reach out to me unless you can't sign in to the system. + +That was it. + +Later I would learn this is the basic project management pattern of [.XP](eXtreme Programming) and Scrum. + +Eventually we got to the point where I was releasing a new version every night. I would email release notes to the customer and await feedback on those items. Eventually we stopped having our Friday meeting. + +After a little over two years the customer asked: + +> When will it be finished? + +I replied: It's software development, it's never finished. + +He asked a follow-on question that escapes me. To which I responded: Let me put it a different way. You'll be finished when you move on to a different project. I'll be finished when you stop asking for things, reporting defects, paying me, or some combination thereof. Someone will always be working on it though. Someone will always be doing something. We finished the baseline requirements six months ago, which was on time for the project's original delivery date. Users aren't reporting defects. Everything since then has been gravy or icing. + +He chuckled and said he understood. A week later we launched the site and they stopped paying me. + +A few months later, I started living in my car. I had succeeded in my mission of making myself obsolete to my clients. + +## 2005–2007 + +Key takeaways: + +1. Learning how to do things others don't want to is an easy way to get an interview. +2. Present win-win scenarios can help you get hired. +3. Internet Explorer 6 sucks. + +I got bored doing Flash development. Once I had hit a certain point, it just wasn't interesting anymore. I'm more in that greenfield and brownfield space, not the farmer space. + +I was in college and still updating the Flash-based portfolio site by uploading images and new versions of my résumé. + +I interviewed as a web designer for a boutique marketing firm in Ohio. I explained that I can do development, but wanted to be more of a UX person. And the whole story from a few years prior. During the first attempt the owner asked if I knew [.PHP](PHP: Hypertext Preprocessor) and [.MySQL](My Structured Query Language). I said no and he said I should learn. + +I didn't get the job. I did buy a book on PHP and MySQL though. + +It was a bit frustrating to be honest. I didn't know how to get to where I wanted to be and it seemed like all people close to the industry wanted to hire me for was to do the part I didn't want to do: write code. + +Created my first CMS using PHP and MySQL. Everything I did for it was about improving the user experience and my definition of what that meant started becoming more broad. + +As of this writing, everything is user experience design for me, the questions are: who are the users and what are they using? + +Quit my job in 2007. Moved to Georgia. Started freelancing as a web developer and business consultant. + +I experimented a lot in this time. One experiment was extending [.HTML](Hypertext Markup Language). Another was in turning a long page of content into smaller pages that were displayed using JavaScript; all the content was delivered but you would click inline anchor links to show and hid sections of the single article. The last experiment was making the site more project-based in its delivery. + +## 2001–2004 + +Key takeaway: Separate content (data) and the presentation of that content. + +In 2020 (well 2010) terms, Macromedia Flash was a single-page, client-side web app. + +A single `index.html` file was delivered to the browser from the host. The browser would then confirm it had the player. If it did, the browser would request the other app assets. + +Three things sucked about Flash when I first started: + +1. You had to wait for the whole app to download, which represented your entire site. +2. If you wanted to send someone to a specific part of the site, you had to tell the person which buttons to click to get there. +3. Which brings us to the third problem, which was caching and updating the site; if you did, and it was cached for the user, they wouldn't see your new stuff (and if the navigation changed, the instructions your friend gave you wouldn't work). + +Eventually things advanced in Flash: + +1. Eventually I got to the point where I could request images and text from the host, without having to refresh the page or update the Flash file; again, like a single-page, client-side web app using API calls ([everything old is new again](https://youtu.be/AbgsfeGvg3E)). +2. Using a little JavaScript, you could read the [.URL](Uniform Resource Locator) (specifically the fragment, or hash) and update the same from the Flash app (single-page, client-side web app); this way you could send the hashed +3. Because the assets weren't part of the app, I could updated the content without updating the Flash file itself. I only needed to do that if I wanted to redesign the site and, if I didn't change where the files were, caching was a non-issue. + +I did almost everything in code at that point; if found the file size become much smaller doing it that way. + +The last version of my site that used Flash was 3 kilobytes. + +For reference, that's half the size of the CSS used for this site as of this writing. That was the animations, retrieving assets, drawing things, and so on. Granted, I was leveraging a dependency that helped make that happen—the Flash Player could be thought of as the packages many of us use today. + +So, yeah, think Angular and similar single-page client-side web app solutions as they were up until around 2015. Or Gmail as of October 2021: + +``` +https://mail.google.com/mail/u/1/#inbox +``` + +Only my single-page, client-side app was in Flash with a little JavaScript, not purely in JavaScript. + +## 2001 + +Key takeaway: Know when to hold ʼem, when to fold ʼem, when to walk away and when to run. + +Started building sites using Flash 4, which is now [Adobe Animate](https://en.wikipedia.org/wiki/Adobe_Animate)…the story I heard about how that happened really opened my eyes to the way the [.IT](information technology) field works. + +I bought my first domain, which was joshuabruce.com, because joshbruce.com was taken. + +I was offered my first web designer gig. I stress the term designer there because I wanted to *design* the pages and tried to explain as best as I could that I "wasn't a developer." That offer fell through though because the contract I was hired for got cancelled. + +I did manage to do a site for the company as a contractor. For the time, it was a pretty nice design that I built in [Photoshop](https://www.adobe.com/products/photoshop/landpa.html?sdid=KKQIN&mv=search&kw=photoshop&s_kwcid=AL!3085!10!79164992492577!79165251442724&ef_id=afed0e5de87c155014a96fd465b3c2bc:G:s) before Adobe shifted to be more multimedia and not so focused on print. This was before the slicing feature was in place and I set up the file to make it easier for the developers to slice and build the site. + +The company had other ideas though and told me to, "Go ahead and put it in HTML." + +I tried to say I wasn't a developer again and that didn't get through. So, I used [Microsoft FrontPage](https://en.wikipedia.org/wiki/Microsoft_FrontPage) to create the pages. The response from the [.CTO](Chief Technical Officer) at the time was that the design was great, the Photoshop file was perfect, but my HTML sucked for someone at my billing. + +Mind you, this was the same person who asked if I was into JavaScript. When I said, no, the next question was, "Oh, you're a Flash-guy, so, ActionScript?" My response was: No, I'm not a developer. I do page layouts, interactions, and arrange the information for the page and the site. + +Anyhoo. + +Dot-com bubble blew up in my face. That company got bought. A couple months later the company that bought them was bought by a third company. (There might have been a fourth.) All the while I'm trying to get my check for this one job. It became a battle on principle, that I lost. + +I gave up trying to explain what I saw as the difference between web design and development and decided that if folks wanted me to be a developer, I would do that. + +I started creating the content management methodology mentioned above. + +## 1998–2000 + +Key takeaway: The Internet is the most accessible platform for creators and consumers. + +Someone I met through [.AOL](America Online) showed me a website they built. I asked how and they mentioned it was something that AOL just had and you could create a personal site. + +They had a free [.WYSIWYG](what you see is what you get) editor. And I created my first portfolio site using that. + +Then I picked up Microsoft FrontPage, which is no longer a thing. + +Think of this like Wix, Squarespace, or similar. + +Tools like these made the Internet feel accessible. Anyone could easily create content and put it somewhere. Not only that but people using assistive technologies could experience the same thing; it’s pretty difficult to make an inaccessible website. + +## Prior to 1998 + +I was online using [AOL](https://www.aol.com), which served as my [.ISP](Internet Service Provider). + +It was fun. Felt like Discord, Slack, MS Teams combined with Apple Messages and a browser. I didn't even know people could access the Internet any other way at the time. I met a few people that way. + +The Internet at that time seemed more about meeting different people and then trying to meet [.IRL](in real life). diff --git a/tests/HttpTest.php b/tests/HttpTest.php index c95e9f31..8d8d375a 100644 --- a/tests/HttpTest.php +++ b/tests/HttpTest.php @@ -4,8 +4,7 @@ use JoshBruce\Site\HttpResponse; use JoshBruce\Site\HttpRequest; -// use JoshBruce\Site\ServerGlobals; -// + test('expected headers', function() { serverGlobals();