For the sake of argument, clarity, and brevity, I am writing to you today to explain Why as opposed to Who, What, When, Where, etc.
Also, please ignore my hash tags this post was originally intenteded to be published to my LinkedIn account.
I can relate to Kendrick Lamar's song i 100% these days. So far I have had 2 companies in Texas try and trick me into using all my time and energy into single handedly solving all their problems while management relaxes and waits for their bugs to get fixed and ratings on the App Store get fixed. Are people really that desperate and flatout dishonest these days? Ther answer is a resounding YES!! No one wants to be your modern day slave while you get a peacful nights rest and go home to your significant other and loved ones on time each day for the sake of a paycheck. "Coders" and minorities such as myself have lives too!! Contrary to what the older generation believes us to be based on our age and, we're NOT research projects and guinea pigs!! We are PEOPLE just like all you cunning and deceitful "managers" and "C-suite" folks who don't have the time or patience to get your hands dirty anymore
I discovered recently (beyond a doubt about 20 mintues ago) that DuckDuckGo’s search results are far purer and more organic than Google’s. Google tries to lure and coerce you into spending money to keep their ad and tracking behemoth fed, while also giving you a false sense of success for using its products (e.g. Advanced Mobile Pages, Google Analytics, Blogspot, YouTube, etc.). There’s no reason my name should drop in rank because I “haven’t published content for X amount of days”. And why in the world would my most relevant website - the very blog you're linked to now be completely omitted from Google’s search results for the past ...like 10 freaking years or whenever I first published content?!?!). This plays right into Google’s favor (reverse psychology). DuckDuckGo on the other hand serves up all the content from by blogs gracefully (the Facebook account
Time for Red, Green, Refactor Must Present Itself (When in Doubt, Do as the Romans Do)
If production code already works (conforms to requirements and is deemed fast enough for end users...which makes it stable)
and does not have code coverage, leave it be until the opportunitypresents itself to add code coverage and
change the code (System Under Test) at will, or a bug occurs related to that code, or it is deemed not
performant enough at a later date. ☝🏽
When I debug front end issues or need to apply styling/markup/content based changes for front end UI code (we’ll stick to React.js based apps for the purposes of this article), I identify a static piece of text that is the same (constant) each time the particular route (most all front end frameworks have routing functionality included) in question is visited (e.g. a piece of text that it is not the result of a JSX expression). Once I identify that piece of text, I feed it into git from the command line prompt. For example, say the homepage has a bug. It also has a heading that reads:
Diversity, Inclusion, and Equality
To quickly determine which source files contain the bug for our ensuing patch (assuming the bug report is correct and it’s not a “user error”), I could:
Easier is not Always Better in Engineering (Client Side and Server Side Alike) ⚠️
by Antwan Wimberly
26 August, 2019
A Note to Junior Developers
It is wishful thinking to assume that just because an application is "easier to write" that it is more maintanable and will result in a stable product being deployed to production. The overall architecture, maintainability, stability, and testability of a given library or framework should always be taken into account.
For example, building a web application via document.getElementById and routine DOM manipulation as opposed to leveraging a more structured framework like Marionette. ⚠️ ...Marrionette.js is an objectively better choice for building large scale applications in contrast to traditional DOM API. The same can be said when comparing jQuery or Marrionette to [`Reac
Why I Did Not Recommend next.js for our Front-End/UI Team
I think next.js is overkill for several reasons and should not be adopted unless your team is either inexperienced or
uncomfortable working with nodejs and babel:
1. crawl bots like Google (the primary target for apps that have a search engine/advertising/marketing need) are now equipped with JavaScript engines and can parse/render react.js SPAs
if your initial render is fast enough there will be no difference end what an end user sees and what the crawl bot sees
Write a JavaScript function unhash(num) to find a ten letter string of characters that contains only letters from:
acdfgilmnoprstuw
such that the hash(the_string) is: