World of Warren

This is a living document post on what I’ve done for this project. It’s to keep track of the Journey.

Here’s a rough total of the time I’ve spent
* 8 hours reading about Python and Flask – which weren’t too useful
* 3 hours playing around with CSS to see if my idea for Chill Penguin would work
* 25 hours improving Chill Penguin CSS
* 15 hours working on Form Elements
* 3 hours improving Chill Penguin core.js
* 16 hours doing PHP / mySQL work
* 12 hours of Bookmarklets / Launch Octopus
* 50 to 100 to ?? hours THINKING

---

2020 04 26: The last 4 days have been looking at Form inputs

2020 04 22: I spent the entire day looking at anchor and buttons. The….entire…..day…..

2020 04 21: Today, I worked on my CSS Classes and Styleguide.

2020 04 20: I’ve been working on my PHP and string replacement, new components, etc.

2020 04 19: It’s been a long time since I visited this project. A little global pandemic kept me a bit busy.

I worked on the Bookmarklet tool, dubbed Launch Octopus.

2020 02 02: I checked buffer size and it’s fine – I can have some decently large files go through the buffer without worry. My concern now is time delay due to recursive SQL calls. I’ll have to check that out later when I have some more complex components. Putting components in components can cause an infinite loop though, which I’ve done.

2020 01 31: I still tried updating Chill Penguin a bit to update it but it’s still difficult. I give up for now.

I hit a major milestone today – the ability to recursively navigate through an array and output the proper code.

This is a fundamental milestone and the key piece for everything that comes after it. I’m a bit worried about buffer size – but I guess I’ll cross that bridge when I cross it. Scalability is Future Warren’s problem.

2020 01 22: Investigating new classes added to Maverick but it’s too messy/difficult. Will use Maverick “As is” – rebranded to Chill Penguin.

2020 01 13: Rewrote Height Equalize component from jQuery to ES6

2020 01 13: Set up Core CSS file (copied from Maverick) but reorganized/rewrote methodology to be cleaner/more understandable

2020 01 12: Set up Core JS file (copied from Maverick) but reorganized to be cleaner

2020 01 13: Pitched my idea to my team. Not sure if I want to proceed with the pitch given that it might not be possible.

2020 01 10: PIVOT! Going with a straight POC/MVP approach – that is, to rapid prototype this solution to see if it could work. No version control. No build. Just code and database. Right into the production server 😀
http://zero-system.poc.warrenshea.com/

• Set up Git Repo
• Added Empty Folder
• Created Python file
• Installed Python
• Installed Postgres
• Created simple http server via python -m http.server
• Picked Jinja2 over Mako
• Picked Flask over Django
• *DOH* – Abandoned Python, Postgres, and Flask for the purposes of the POC. Going with PHP, mySQL for now….

• snake_case: JS/PHP Function, Database name, Database Table names
  After carefully playing around with camelCase, kebab-case, and snake_case, I have decided that PHP/JavaScript functions, Databases, and Database tables will be **snake_case**
  
  I am personally a fan kebob-case but it doesn’t work for all of the following: PHP/JavaScript functions, Databases, and Database. Sometimes I write camelCase things but personally, I find it takes slightly more effort to read/understand.
  
  
• kebob-case: CSS Class names, URLs, HTML attributes, PHP to be replaced {{hotspot–0}}, Filenames
  I have decided that CSS classes will be **kebob-case**. This is mostly just personal preference. I dislike camelCase for CSS and (maybe out of habit?) dislike snake_case for CSS.
  
  Modifiers will also start with –,
  e.g.
  * anchor.php
  * anchor–new-window.php
  
  Language differentiators will have a .en or .fr at the end
  e.g.
  * anchor.en.php
  * anchor.fr.php
  * anchor–new-window.en.php
  * anchor–new-window.fr.php
  A file with no differentiator will be language agnostic.
  
  
• indenting will be 2 spaces
  
  
• uppercase characters will only be use for things outside of this system’s control
  
  

Code

• Minor – Rewrite core.js getBreakpoint function
• Minor – Modify Gulp process for Dev env CSS (to not show comments) – if possible
• Medium – Remove jQuery from Core JS

Architecture

• Add SourceMaps

Features

• PubSub
• Load JS Dynamically
• Helper Pages / Tools
  • Full URL Sitemap w/ French counterpart
  • Most frequently used classes (total)
  • Page for all classes inside database (for tree shaking)
  • Analytics – What component is used most (counter)
  • What component is used where
  • Background image viewport checker
  • Page for Databases
  • AB Testing
• JavaScript Bookmarklet checker
  • Check Analytics is there
  • Check no duplicate IDs
  • Check HTML validity (UL/LI)
  • Heading checker
  • Check HTML validity
  • Validation checks for “Free content” spots
  • Word to code converter

https://en.wikipedia.org/wiki/Necessity_is_the_mother_of_invention

Heard this when wife was watching Little Women. Thought it was a very interesting proverb that related directly to this project.

This tool that I’m “Inventing” ultimately solves the following needs:

• A git-based system version control system separate from code.
• A way to build/edit/deploy web pages via a GUI.

After a number of project redesigns throughout the years, redesigning three 20+ page sites, I started coming up with a different way to do CSS. BEM, ITCSS, OOCSS – they weren’t working for me or my team.

It started with the issue that headings were designed certain ways but tying the look of these headings to designs AND making them semantic and accessible HTML across the entire page was problematic. Design wise, the page would look fine, but the page heading order would be something like: h2, h1, h2, h4, h4, h3 – you get the idea. So the idea was to decouple styles from semantics. Specifically, look and feel should not be tied to any DOM element selectors.

Combining some things I learned from Foundation, Bootstrap, and Flexbox, I created a utility-based CSS system. I called it Maverick.

I used it for more projects and was convinced it was the future of CSS. It was great! I pitched the idea to my team – it was a difficult sell because it went directly against how we’re taught to do CSS. But they were open to the idea and adopted it as part of their codebase. I think it’s been working out well and I see very few drawbacks using it. I still think it’s the future of CSS.

This is not part of the story but related – after doing more research, I found out someone else, Adam Wathan, had already created a CSS methodology and system similar to Maverick, called TailwindCSS. While I don’t agree with everything in TailwindCSS, it’s identical in theory and about 90% the same. If you’re looking to try this CSS technique, give TailwindCSS a try.

Anyway, the point of this story was that I had to challenge what I knew and what I was taught regarding CSS. I had to have the confidence to do something I felt was right, despite being against everything I was taught and what my team believed in. This project, Zero System, will be an extension of this confidence and direction. Challenging what I knew or thought I knew. Doing some things that, I already know, will be unpopular decisions.

On the plus side, I’m re-evaluating things that I always wanted to know about and/or going back to things that I found difficult. I’m specifically learning more about performance and I hope to learn more about Design Patterns, APIs, HATEOAS, Python, and Postgres.

On the negative side, it’s taking me quite a while to get started on this project. I have the idea in my head but executing it and using new technologies, has become a bit of a blocker and a burden. Still, I hope to come out wiser after all this and in the end, isn’t that what it’s all about?

This blog will keep track of my thoughts and musings as I work through a new project, dubbed Zero System.