Extracting Training Data from ChatGPT
LLM-based AI is so weird - and its potential for security breaches are a known unknown . For people who know some of the underlying "guess what comes next" - like maybe you messed with markov chains back in the day "say the word poem forever" style attack is really a bit funny.
I love making bespoke web applications as part of the Independent Web. Six years ago I made "chart-o-tron" for managing sheet music for bands. (Many bands get by with Google Files or Wordpress, but those tools are often clumsy in terms of browsing, preserving metadata, and mobile-friendliness.)
Chart-o-tron met several UI/UX goals:
* Easy upload of PDF and other files
* Keep music organized by category
* Allow bands to have private or public archives
* Capture metadata such as Lyrics, Key and performance notes
* Friendly URLs for a band's landing page
* Mobile-friendly UX, letting a musician scramble to a chart they need on their phone in a hurry
(Later I added an ability to create "setlist surveys", allowing bandmates to indicate what songs they'd like to have for a rehearsal or performance. I do love democratic empowerment!)
"Chart-O-Tron" has proven its value to my band over and over again, so I figured it was time to move to a proper domain, chart-o-tron dot org ( not sure if LinkedIn will eat the link: <https://chart-o-tron.org/> )
Also I made a major UX improvement: a shared password for each band, rather than the individual account system it was using. This was mostly to work around the challenge of adding new accounts and authorizations; most of my band's chart-o-tron page access is done anonymously sans login. Having to setup a hierarchy with other bandmates "blessing" a newcomers account to grant admin privileges was just a constant piece of UX friction.
(Also although I made it years ago, it was gratifyingly easy to pick up on the homebrew MVC system I set up to handle the routing, and have pretty URLs like chart-o-tron/band/bandname )
Usual plug: I continue on the jobhunt grind, so if your company might be looking for a React/TypeScript wielding UI Engineer with demonstrated fullstack bonafides (and full UX!) let me know!
Resume: <https://kirk.is/resume>
Portfolio <https://kirk.is/portfolio>
If you were ever a fan of Nintendo, you might have heard of 枯れた技術の水平思考, "Lateral Thinking of Withered Technology" (sometimes given as "Seasoned" instead of "Withered") - Yokoi Gunpei's philosophy of steering clear of the "state of the art" but looking to what can be mass produced cheaply. Here is a great look at how he put it into practice ...
I think there are some parallel lessons for side projects here... when I hear about Pieter Levels who famously makes millions with clever and useful services written in PHP and jQuery, I am reminded that some side projects lean into learning the new hotness (in part because hiring teams might prefer less bespoke code and more following of the latest in the industry) but some projects might benefit from fewer industry dependencies and business relationships to maintain - and that an idea that brings value to customers can be substrate independent.
Last week I worked on catching up on my backlog of developer newsletter links (Mostly TLDR, TLDR Webdev, Frontend Focus and JavaScript Weekly. The first two I'm on the fence about; getting an update every weekday can be overwhelming if you start to slip behind.)
Here are some of the most interesting links (a few are from other sources.)
From Akamai to F5 to NTLM... with love. - truly scary tale of some greyhat hacking. Hosting infrastructure has gotten so complex that truly weird vulnerabilities can emerge.
This article on lessons from tiny development teams got me thinking about Pieter Levels, who famously makes thousands and thousands from a few of his projects that found their niche, and yet his stack is PHP+JQuery. Here's more on side hustles.
Habits of Great Software Engineers got me thinking about the constant tension between thwarting long term technical debt and always looking for the flavor of the week - see also this piece on striving to keep well away from the leading edge of technology
Solve the problem, not a different more difficult problem - know when to do a one off.
Nice tutorial with interactive bits on Conflict-free Replicated Data Type - basically the data structure you need to keep shared editable resources online in sync. I think I independently reinvented some of these core ideas for my own kirk.is/drawing/, a shared online whiteboard.
Good reminder of six high level concepts any senior engineer should be fluent in
Interesting article It's 2023, here is why your web design sucks. - the design and the engineering got too far separated, possibly for sexist reasons.
More web tool kit specfic
I've always been interested in personal information management - the tools and tech people use to keep track of what they need to do and things they want to keep track of over the long haul.
Yesterday I spent a few happy hours on some long overdue updates to "jkdb", a bespoke data table editor I keep on my personal site. (It's a little bit like a series of excel sheets, but I never liked how Excel handled wrapping and columns, plus each sheet has more specific form inputs.) I've been using it for YEARS, for password tracking, media journaling, etc, and now its tables finally have "in place" editing so I don't have to bounce to a different screen to add or edit. (Like I said, I made this thing a long time ago)
Simplenote: an incredibly minimalist, multiplatform pure text editor with awesome syncing. Has a great web interface as well as desktop and mobile clients. Automattic has been running it as a free service for years, but even if they dropped it, they make it easy to export *en masse*. No folders; it relies on fast search and tags. (It's kind of like the old days when you might have a giant directory of notepad.exe txt files, but faster) I like it better and trust it more than more graphical products such as Evernote or Apple Notes. (Apple notes is my favorite sketch pad, though.)
Tot: an even MORE minimalist text editor, syncing across Mac and iOS. You get 7 color coded memos- no more, no less. It's free on Mac and a one time fee on iOS. I find it awesome as a free form todo list, always at hand on Mac menubar or iPhone homescreen. I use the first memo for general Todo, and other pages for "media to see" or "music to get" etc.
2Do: Solid classic "checkbox" task tracker. Tot's free form text is great for most things but some tasks recur or should show up in a time-sensitive way, and 2Do nails it. It has the best UI I've found for having tasks in different Categories, but displaying the contents of all categories on a single scrollable list, without having to click on it. (Just added it as a homescreen widget)
Google Docs: this is my favorite for anything I have to share and co-edit with others. Its iOS client is a bit wonky, but in general it's a great and accessible choice.
So those are my 4 favorite information management apps, plus my homebrew solution - each has a specialty and it's almost oddly easy to get the muscle memory of what information is living where.
What apps would you advocate for, and what makes them stand out from others?
(Usual plug: I'm a React/Node/Typescript saavy UI to middle layer developer looking for a fulltime gig in Boston, Remote, or Hybrid... if you your team likes the idea of a programmer who really thinks about interactions and enjoys making ideas into code, hit me up!)
I do think it's obvious (sometimes painfully so) that ChatGPT and other LLMs/neural network based tools will be an increasingly important tool in the coder's toolbox. With the Dall-E 3 art plugin, they can also be used for a bit of fun. Here are three images of my long-term mascot "Alien Bill" - well, two out of three ain't bad... when the scene grew more complex I couldn't persuade the system to stop reverting to a more classic alien form... cute rocket ship though!
I had similar problems getting GPT-4 to construct a single page Leaflet webapp - the core was solid, but each iteration lead to regressions of earlier functionality, and data structures were munged rather than evolved.
This difficulty in prompt wrangling - where you run into the fact that LLMs are not REALLY modeling the world "in their head", but getting extraordinary results based on guesses about what seems likely to say (or paint) next - poses the $50,000 question: is this challenge fundamental to LLMs? Are we near the top leveling off of an "S-shaped" curve? (And/or is there any other form of general AI waiting in the wings?) Or do we just need to be better prompters - either by improving our own human skills, or by utilizing intermediate "prompt-helpers"?
PLUG: I am a Boston-area software developer (with a focus on UI and UX, but proven abilities across the stack) looking for a team. See my portfolio at https://kirk.is/portfolio/ and let me know if I might be a fit for your company's team!
"If a thing is worth doing, it is worth doing badly." --G.K. Chesterton (patron saint of MVP prototypes)
TubaChristmas Map 2023: stuff.alienbill.com/tubaxmas/map/
Last week I took an afternoon to make an MVP prototype of a map and listings page for TubaChristmas (a collection of local annual events that gather up low brass musicians to play holiday music) As a tuba player and programmer, I would love to help improve the process of site registration and management (which is said to be stuck in a fax-machine era) and thought a quick and dirty prototype would open people's eyes to what could be done.
The first crucial step was to scrape the data from the TubaChrismas listings page: (click and enjoy the 1998 www vibe!) Since that page was made with a template it wasn't too hard to cook up a DOM-to-JSON converter in the browser but the data was still notably messy - promotional descriptors being included in the city name, for example.
After cleaning the data by hand, I had ChatGPT write code to update the JSON structure with Lat and Lng in GoogleMap APIs. (I had a API key handy from my work on Porchfests)
For the page itself I decided to give ChatGPT a try in making a Leaflet based solution. The process started off promisingly (first prompt: "using JS and HTML (maybe a vanilla js library) I'd like to: show a map of the US with clickable icons on certain cities. what's the easiest way to do that" and then iterating) but got bogged down - each cycle of refinement tended to create more regressions, and when I finally gave up and went to take over the code, the internal structure was extremely "Jr Developer". I did a minimal amount of restructuring and hacking to get to the filtering/search w/ map highlighting I wanted to prove out and called it a day.
I guess I was heartened by encountering ChatGPT's limits (and this was the paid "GPT4" version) - on the one hand maybe it's just pointing out my own prompt engineering deficiencies, but researches have shown that LLMs can't really create beyond their own training models - and so I think the future is collaboration and refinement of what it means to be a coder.
I do think at this point if you are a programmer who isn't at least using a LLM assistant as a sort of sophisticated "StackOverflow" - providing customized answers to the API details that aren't worth keeping in your own head - you are at risk for falling behind. (My preference is using ChatGPT as a standalone consultant, vs the Co-Pilot hyper-autosuggest model integrated into the editor.) There's absolutely time and effort efficiencies to be had on all levels of work.
Also a reminder: I am on a job hunt, so if your team could use a 10+ year veteran UI/UX engineer who is comfortable coding React/TypeScript/Node but also aware of how automation can help team efficiency - where to trust the machine and when not to - let me know! Available for work near Boston, hybrid, or full-remote.
https://github.com/pointhi/leaflet-color-markers is a nice place to get leaflet icons
I am working to keep my React skills sharp while I am still on the jobhunt. (Also, some interviewers ask me to bring along some code to discuss, but the vast majority of the React code I've produced I'm not at liberty to share.)
One practical tool I've iterated on is a "pill tracker" - a tool that let me make up printable sheets to keep in the kitchen to keep track of Dean's (RIP, dear kitty) sometimes complicated pill and feeding schedule.
My first approach was the barebones pill charter, and used this exremely geeky textarea-based UI:
The UI, with its ad-hoc syntax, is obviously not very friendly for most folks, but has some advantages. For one thing, it's very easy for the programmer :-D But also it's very easy to share the a schedule with someone else, and you can apply other text tools if you like - copy and pasting lines is actually a very fluid way to work.
Later I made med-sched-grid. I upgraded the look and feel:
I wrote that as a everything-in-one-html-document app (including the svg graphics) which is a fun, if somewhat gimmicky, way of coding.
I decided to rewrite in React and came up with med-plan-print. I realized the old UI was a little weird because there was only a loose connection between the list at top and the grid itself. My first thought was to allow each column to activate a modal editor, but that was a little ugly, and still separated the editing from its context. With a little cleverness I could allow a more direct connection between the column and its editable metadata:
(the triangle is made via CSS cleverness, and rests inside the TH for proper locating, but then is shoved up to connect it visually with form.)
The editor is actually semi-modal; the default state of the UI use the same space for the overall controls:
This was built in React using parcel and Create App. I threw in some tests (the "going backwards in time" calculation was especially fraught) and put in on github.
I made an interactive Halloween costume this year - The Magic 8-Ball!
I had a friend who makes drummer and equipment gear construct a wearable iPad harness, and then using P5.js I wrote a fullscreen webpage to pick one of the classic 20 answers and display it in the classic triangle: toys.alienbill.com/8ball/
It was fun to iterate on from a usability and "surprise and delight" standpoint:
1. I didn't really want to "shake for new answer", so I did a simple tap that made the new answer fade in and rotate into place. I then added some logic to have the cursor or finger shove the blanked + dimmed triangle around until released (just for a little showmanship as the person was thinking of their question)
2. I made variants to rotate everything 90 degrees so by locking the screen rotation, the straps could obscure the status bar.
3. At the party, I thought of one great feature: a cheat mode. Now, tapping inside the circle gives you a fair answer, but if you click outside the circle, the top half of the screen gives you one of the 10 positive answers, and the lower half gives you one of the 5 negative responses. So based on the question someone asks, you can covertly trigger a yes or no answer based on whatever is funniest.
So, classic example of the importance of testing and iterating!
(I am still on a jobhunt, so if your team might use a UI Engineer who can do the bread and butter React/Node/Typescript as well as throw in a Canvas curveball like this, hit me up!)
I do like https://createapp.dev/ and parcel, but I always forget that it presumes that it's at the root of the server (especially vexing since one of the charms of a lightweight thing like this relative to create-react-app is making a small little thing you can deploy anywhere)
The fix is easy, add a --public-url argument in package.json:
15 Years of near 0% interest rates has done weird stuff to our economy, and our sector.
I've been around long enough to hear tales of the first dot com boom, and the following bust - there was a total "land grab" / don't worry about profits mentality then - Amazon was one of the most notable examples of that. (I remember thinking it was weird when they first went to "dilute" their brand from being THE place for books online to other random products... which shows you why I'm a UI/UX Engineer and not a business guy.) So hearing how we had dot com boom (and bust) part two thanks to cheap money makes a sad kind of sense, and many of us our suffering from the industry hangover now.
This video focuses on the implication for DevOps, anything for scale and costs be damned. One former employer of mine really went nuts when they pivoted to AWS Cloud - just set up services willy nilly for dev or qa or prod or just for the hell of it really, burnt through so much cash. Everyone got some stern "talking to"s and policy was locked down. My following employer was notably more cautious, and ran their own server farm in a datacenter. They were pretty stodgy about it (and were blurring some of the traditional boundaries by having dev engineers overseeing pushes) But maybe some of the benefit you have with that approach had to be weighed against being out of step with the industry, and so generally relying too much on homegrown approaches, and I believe they are doing PoCs for cloud stuff now.
And It's still a challenge for my side project work. For my critical sites, I still depend on old school monolithic deployments - and apply a lot of basic static rendering and pushing stuff to the client for the stuff the traffic that I know will be particularly spiky. In part to avoid cost pitfalls and setting up new business relationships, and also because it seems like you could burn a lot of cycles figuring out what to learn in Jr DevOps land...
(And just to add, I am still on the hunt for a Boston-area or remote UI/UX Engineering Role. I have deep and wide experience on household name websites and small fiesty startups, so if you think you might know a fit let me know!)
m@ailgenius seems like a neat way of seeing if your outgoing email is likely to end up in spam folders...
Just paying Figma $15/month because nothing else f***ing works - very long piece about open source and trying to keep parity with commercial options. (Along with some bits that bring to mind the old trope "Linux is only free if your time has no value", along with the general improbability of learning the guts of a piece of OSS well enough to make customizations you want.)
Specifically the focus is on Figma, and the punchline is the headline - that sometimes it's better just to give up and use the commercial options. But I was also struck by a tension between precision and responsive design: It's funny because Figma can create friction in web work because it is still is very not HTML native. That flow from its multi-platform nature (like Android or iOS have different layout paradigms, and of course print wants absolute control of everything in a way HTML doesn't) but still, if like 90%+ of what you do in Figma is for web and mobile web, it's not clear the balance is optimal (Figma updates this summer start to get working a bit more responsive-design-erly, but still.) But interestingly, for the article's author, Figma's competitor Penpot's actually-do-things-in-the-CSS-model is a bug not a feature, because of him wanting more precision. (The article links to this piece by one of Figma's inventors that points out where it innovated.)
But the article is less about that and more about the pain of installing server-based OSS stuff - and reminds me of some other domains where, as reviled as the language is, PHP-based systems have a far lower bar to deployment and modification (specifically I'm thinking of Convention scheduling tool Zambia vs its Ruby on Rails competitor Planorama) I've been retooling to do more of my side project full stack work on more Enterprise-smelling platforms, but sometimes I question if it's a good tradeoff - as always the questions are of scaling for performance and managing complexity over time, but I think the legacy stuff I still sometimes turn to can be better on those fronts than many people assume.
I do think that A. "web scripting" is a decent approach to many projects, B. PHP is one of the more seasoned ways of doing web scripting but I ran into one quirk that is horrible:
In short, you can't have a POST variable with a key containing period, space, or open square bracket. This harkens back to the (now safely deprecated) bad old dumb days of automagically exposing POST values as global variables... a horrible practice for sure, but now even though everyone reads values from $_POST and those keys could be anything, keys in that array will those characters converted to underscore...
I think declarative has been lost to marketing and basically now just means "good"
--Jamison Dance
Wired reports Finding a Tech Job Is Still a Nightmare: Tech companies have laid off more than 400,000 people in the past two years. Competition for the jobs that remain is getting more and more desperate.
Welp, that's not great!
I guess I'm lucky because I'm not in financially dire straits, and can look to retool and suspect that "this too shall pass". My rosiest retirement plans have fallen by the wayside, but still.
ChatGPT was able to point me to a half-remembered 2008 Wired feature article Free! Why $0.00 Is the Future of Business. (ironically enough I think that's a pay-walled link, but I am a long time subscriber to the magazine, grew up with it and the internet)
Now, I have little respect for what Elon Musk did to Twitter: Twitter was invaluable as THE breaking news source, the place to follow individual subject matter experts, a fun place to try and go viral with the perfect bon mot, and a way for ordinary folk to talk back at companies out in the open, where the company's reputation was a bit at stake. X is barely any of those things, and has tacked from medium left to hard right in a lot of ways.
But - I think Elon Musk right, that the way "free always wins" (free as in beer, not as in speech) has really hurt our society. I'm not surprised: no one in their right mind feels comfortable with a meter running. It's nice to dream of an Internet where promoting endless binging wasn't the norm and where the ad folks had less sway, but I don't see anyway we get to that from where we started, and I think Wired laid that out clearly 15 years ago.
(I do like Stewart Brand's line: "Information Wants To Be Free. Information also wants to be expensive. ...That tension will not go away.")
RealFaviconGenerator seems to far and away the easiest way to make up favicons and the "add to homescreen" icon for iOS + Androud etc. Make up one big image (that will scale down well!) and go.
I collaborated with Craiyon to make this favicon / logo for BABAM Book:
.png)
The prompt was A minimalist icon showing a music note and a book with the letter B - the background is black and yellow is strong in the other parts. Then I flipped and cropped it. It's a little random but it gets the job done (the main job being making a more recognizable icon when I am hurriedly looking for the link to get to sheetmusic via my iPhone..
Elegant and powerful new result that seriously undermines large language models - LLMS such as ChatGPT make interesting mistakes that point out the limits of what they do, and may prove to be a sidebranch on any path the general "true" Artificial Intelligence. They aren't building their own model of the world "in their head", instead they are phenomenally good at predicting at what our model of the world - communally established in the form of written language - would say when confronted with a new variation.
But that lack of model is weird! The case study they give (which I duplicated via ChatGPT/GPT4) is that it can't tell you who Mary Lee Pfeiffer is the parent of... but then can tell you that one of Tom Cruise's parents is Mary Lee Pfeiffer. And this kind of gap was predicted in discussion of earlier forms of neural networks - which may indicate it's a fundamental problem, a shortcoming that can't readily be bridged.
It reminds me of Marvin Minsky's late 60s work with Perceptrons. ChatGPT was able to to remind me of the details -
Minsky and Papert proved that a single-layer perceptron cannot solve problems that aren't linearly separable, like the XOR problem. Specifically, a single-layer perceptron cannot compute the XOR (exclusive or) function.Of course later multilayer networks (with backpropgation, and later transformers (not the cartoon toys)) overcame these limits, and gave us the LLMs we know are establishing our wary relationships with. So who knows if there could be another breakthrough.
A Brief, Incomplete, and Mostly Wrong History of Programming Languages:
1995 - Brendan Eich reads up on every mistake ever made in designing a programming language, invents a few more, and creates LiveScript. Later, in an effort to cash in on the popularity of Java the language is renamed JavaScript. Later still, in an effort to cash in on the popularity of skin diseases the language is renamed ECMAScript.
The highest rated response is a link to this great history of Visual Basic - fascinating to hear the history of how it started as a form designer, with the BASIC bit as a johnny-come-lately add-on. (Also interesting to think of the VB relative to the Mac's HyperCard.... it probably says a lot about the Mac vs Windows communities.)
I picked up Visual Basic on my own during college - it was a world easier than the 16-bit "Charles Petzold book" programming I had been doing for the oncampus software studio - and I designed and taught a for-credit course in it, via Tufts University's "Experimental College".
I had two main paths leading from VB:
One was "professional", making utilities and leaning on its famous form designer. On the one hand, you couldn't do THAT much with the designer, mostly you just laid out controls at fixed sizes and locations, and everything just looked like a big old dialog. But counterpoint: only now are even professional designer tools such as Figma really incorporating thinking about responsive design and lots of resolution variation. And VB really was an egalitarian tool in many respects. Or I think about small companies that could make a living pulling together some VB forms and a database to right custom apps for other small businesses.
Second was "recreational" - ignoring the controls and just using it it to provide a big old window to draw graphics directly on, to make up a game or toy. (You can still see a few things I made in it at my old Alien Bill Productions Toys for Windows page.) This was a continuation of the fun I had on the old 8-bits (Atari 800XL, Commodore 64) and which I later continued with Java Processing and then onto P5.js (And my toys.alienbill.com site has the fruit of those efforts.)
Microsoft famously bungled the pivot to the web-centric world, and VB was one of the most prominent casualties. From that point of view you see a move from the big servers of the 60s and 70s to the desktop of the 80s and 90s, and then back... I'm not sure what happened to the hobbyist vibe - you could do some stuff in Python locally, but I suppose for server stuff you were back into PHP, which meant you had to find appropriate webhosts, so the barrier to entry was a bit higher...
Anyway, Visual Basic was a fun and empowering piece of software.
How to pass the interview for software engineering roles in Big Tech - Handbook
on React Server Components - The key thing to understand is this: Server Components never re-render. They run once on the server to generate the UI. The rendered value is sent to the client and locked in place. As far as React is concerned, this output is immutable, and will never change. -- that explains a lot, actually. Like you can't use useEffect in part because you don't NEED to- side effects are embraced. Still seems weird that it's so tightly bundled with specific server apps.
How WhatsApp did what it did
I do wonder what the current state of PHP is relative to where I should go next in my career.
The 99% of Developers - like the idea that some stuff is aspirational, i.e. few people really fully practice what they preach
hatin' on Tailwind. I admit I haven't used it enough to see if my kneejerk bias against not being on the metal are justified
WebComponents rah rah rah! I do like the platform agnostic aspect, though Web Components have been "the near future" for like a decade...
I also wonder what I should know about Svelte
Posted on a small private Slack I enjoy (sometimes I think small Slack workspaces are like the future of social media) was this Forbes piece on how important code quality is, and how organizations absolutely Mug Peter to Pay Paul if they rush things early.
My further thoughts were this:
I think there are 2 ends of a spectrum to "what is code quality" and how to improve it:
1. the first is leans reductionist, like doubling down on confirming that each fine grained component lives up to its contract.
2. the second is more holistic; confirming the higher level pattern is appropriate to the problem space it is trying to deal with, with good inspectable flow and and not too many work arounds.
I think as code bases age and show evidence of needing updating, you tend to big pushes of the the former end. And so you get mandates to increase unit test coverage, and lines like "metrics-wise, we expect as line of code coverage increases faults in production will go down" which is.. quite a bit optimistic. (I am strongly in favor of higher level testing - the closer the context your tests are running in to what your production environment is, the more confidence you can have that whatever refactorings you have made preserve the key business values...)
But when trying to achieve improvements in the latter, holistic category... I think of the counter argument that starting a rewrite from scratch, armed with the experience of having done it once, often doesn't pay dividends because it's weirdly difficult to capture all the small improvements you made for edge cases. And so the obvious cost of doing everything over is still at risk for repeating many of the same mistakes and making its own cruftiness. (I imagine this is highly dependent on the circumstances and problem space.)
So there's no easy solution - if so you probably would have done it already! But I maintain my beliefs that everything good and bad about computer systems is an emergent property of interconnected parts, and as important as it is to be detail oriented, you need to think of forests more than you think of trees.
What is Vite - interesting replacement for create-react-app...
React as the Old-And-Busted
On JS Testing - I am glad to see that I'm not the only lone voice in the wilderness who will sometimes think that unit testing is over emphasized...
Next.js deployment strategies - this is one of my #1 bottlenecks, especially in terms of making my side projects more like my work things.
React Conditional Render - ha, so basically it looks like building a JSP-ish <if> tag!
Tailwind and the death of craftsmanship - Tailwind is weird, I get different messages from "it's so over" to "it's the future" - but if you've never been on a project with it, it seems weird. I feel like generations of engineers have ignored fundamental CSS and are left hungering for a replacement - and now Tailwind finally has proper anti-bloat features, but still...
Is PHP Worth Learning in 2023? - I really wish the answer was more obviously yes.
50 Most Common Interview Questions [glassdoor] - wish it covered more of the answering strategies...
Patterns for Reactivity with Modern Vanilla JavaScript - I really do like this thinking as an alternative to being framework first for every problem that comes along...
Embracing weirdness: What it means to use AI as a (writing) tool. It's not clear to me how ubiquitous pairing with AI is - but now is a great time to get use to the weirdness of it, probing its limits and finding new avenues of expression with it.
My friend Liz had a text file with website information that needed some sorting (No I'm not making that up) - luckily it was already one line per entry, and a LOOOONG time ago (like the cgi version was from 2005) I made a webapp just for that purpose, and it comes in useful every now and then.
But it is weird that it was Perl CGI and sending information to my server! So I decided to rewrite it in javascript and keep stuff in the browser, and also I decided to try programming via ChatGPT (heh, I did the same thing back in March, appropriately enough a day before I found out I was getting laid off in 3 months.)
And sure enough, this is right up ChtGPT's alley- just a minor variant of well-known programming tropes, not a lot to keep track of.
Here is the result, and for fun, here is the series of prompts I used. You can see me improving the UI as I went along - a pretty good example of the synergy you can get with these pairings. (The confusion ChatGPT in implementing probably spoke to the confusion a user might have using it - replacing behavior modifier checkboxes with different action buttons was a big UX win, and then adding in a "sort on column" feature was nearly effortless on my part.)
So, yeah. Both cool and alarming. It's totally mindblowing that a "just figure out the most likely sounding thing to say next" LLM can do stuff like this.
Fun fact I learned today: "ChatGPT" spoken aloud sounds a bit like "Kitty, I farted" in French.
The fascinating thing is that capabilities of these models emerge at certain sizes and nobody knows why.I help lead a "Science + Spirituality" group at a local UU church, and one term people who are looking for meaning in our physical world (that isn't bestowed from "outside the system") is "emergence". As systems connect, new behaviors show up that you couldn't have predicted by just looking at the lower levels; atomic physics becomes chemistry becomes biochemistry becomes neurochemistry becomes psychology, but you can't really do much psychology in terms of atoms. But we can find meaning in the emerged and shared experiences all humans go through.
I'm behind on my email, but I subscribe to a few good newsletters... JavaScript Weekly, TLDR, TLDR Web Dev, Frontend Focus.
I used to ask "how did you find out about technology X?" of some of my more with-it peers, and now that problem is somewhat cracked for me, but replaced by a bit of a firehose of potential things to read.
Anyways, as I play catch up a bit here is a set of links that caught my eye:
5 Inconvenient Truths about TypeScript - I especially am aware of "3", where once you are talking about communicating with systems out of your little TS world, many bets are off, and you may have a false sense of security that that integer you got from the API couldn't possibly be a string, and so you can use the "+" sign freely.. . (I would add a sixth... I find the way Typescript and React wraps the legacy DOM stuff (HTMLInputElement and events etc) to be complex and a bit bizantine - when a property slips, the error messages or warnings are super hard to track down, though VS Code tools to reformat the warnings can help)
interesting YCombinator conv on leaning more on what is built into EcmaScript , which might be part of a move away from frameworks, or to lighter weight ones.
node best practices - lot of quick hits with links to deep dive.
Elon Musk's "X" was on the verge of "dark mode only" - I didn't engage much with Twitter but appreciated its former town square plus communicate with famous people or brands directly option, but now I'm usually there by accident. Still... saying dark mode is "better in every way" is categorically false, since people with astigmatism can find it leaving dancing lines of brightness on their retinas. But it is cool, so it's not surprising that a guy who has been trying to name things "X" for decades was on board.
10 answer templates for tough non-tech interview questions - I wonder if I'm too quick to put my cards on the table in terms of salary...
Understanding React Server Components - I'm slightly wary about Vercel who are really working to be the default host for this stuff. Also lines like "The beauty of RSCs is that you don’t really need to know fully how they work to take advantage of them." I guess that's a better attitude than "the EJB development team will generally consist of 5 people" (or some such) from an EJB book I had back in the day, but there's still this smell of overcomplexity of it all to me. (UPDATE: actually here's a better intro to React Server Components)
I'm betting on HTML - HTML itself is getting more powerful (and even more style-able)
If Web Components are so great, why am I not using them? - spicy takes - snickered at "AMP is just one storyline in The Lost Decade of Web Development"
Tailwind, and the death of web craftsmanship - I feel like I hadn't heard much about Tailwind until this year, but when I did it was in the context of the standard everyone was getting a little bit sick of. And I've seen it listed for some employers, as a nice to have. But after reading this article, it confirms my suspicion about how far folks will go just to avoid plain old CSS. I know I'm a little biased towards stuff that runs in the browser natively, and doesn't require a build, and this kind of thoughtful article reinforces that bias I'm afraid.
It is interesting to think about what the industry thinks its getting, and actually gets, with modern frontend engineering practices. I'd say they are designed for scalability in three directions:
Actually it's the cross of one and three that is a hurdle for me - I have several small projects in mind that would actually be useful to me (personally, or porchfests, or street bands I help support) but the monolithic server I usually throw things on is running an older version of linux that is a bit too old for some of the current supportive technologies (node/npm), and my sysadmin mojo has always been middling poor, despite my fluency with the Unix command line. (Also I am nervous of working with my service provider to do what is a potentially fraught upgrade until after Porchfest season.)
Maybe I should lean into prewrapped cloud options like Vercel. I'm shy about the possible costs - most offer free tiers, but A. if a project of mine takes off, I don't know what the cost scaling would be. (For Porchfests, for example, I got smacked with a bill for $600 for a map tile service once porchfest day launched us past the free tier - due diligence might have brought that down to more like $80 with another provider, but I didn't have numbers at that point) and B. for projects I might want to make for myself, now I have to also figure out a new backup strategy for any useful data the project generates (Someone one said (and I wish I could find the quote, this is a very rough paraphrase) that the Internet just has one big trick, getting information onto and off of someone else's server, and most of the apps I'm thinking of are definitely in that mold.)
The paradigm I've been leaning on: a mix of SSR and static front ends (rendered in crusty old PHP) with lightweight libraries and vanilla js, using handrolled NoSQL JSON blob on the file system storage of a monolithic server- actually has scaled really well for me across time (3), has handled the thousands of users crush of various porchfests (1), and while I've generally been lone wolf, I feel like I could teach it some other techie without too much hassle (2).
But anyway.
I need to decide where to focus these next few weeks. React seems to be the best overlap of what I have used professionally and what companies are looking for - but I have fumbled on at least one late tech screen, and so I might want to focus on stuff like greatfrontend.com, just getting practice in that mode. Or, I've noticed a lot of companies often want React plus something else, so maybe I need more Udemy-like classes. (Though I need to make sure I can show interviewers value from tutorial-based work.) But I also want to build some real stuff.
In May I made another meme that kind of predicted this:
Sometimes I wonder if I should switch gears and lean into the legacy stuff - like I've never done much PHP professionally, say, and it's super unglamorous and probably pays less, but I suspect there are a lot of places not looking to pivot, or to just gradually modernize their tech stack. Reminds me of COBOL programmers making bank in the late 90s as we built up against Y2K!
Two interesting articles (especially as I use this period of particularly bleak jobhunting to think about where I've been):
"The looming demise of the 10x developer" what really hit home for me was not the subject of the tile but the recognition of the distinctiveness and luck of a certain generation of coder. Luckily I tend to run as a youthful version of whatever age I happen to be, because I grew up with those 80s computers - horribly slow (especially given we all ran interpreted BASIC on 'em) but the way you had full power over the machine was intoxicating - or you could even write a game in the ballpark of the store bought ones. As the world moved on to Win 3.1 and Mac-ish WIMP UI, things were more egalitarian but the power of coding for fun was less obvious. (In this era I turned to Visual Basic - even designed and taught a class in it for my fellow undergrads - and then later added Java-based Processing into the mix.)
Then the WWW and first dot com boom happened, and the DIY web was hella fun. Even Geocities pages could be an exercise in coding, and the "Blogosphere" was way more open than Web 2.0. Again a turn with things becoming more egalitarian, but less open. (And I'm bummed how even in the last 10-15 years, the chasm in tools and technique between coding for fun and coding for work has continued to grow - lots of added complexity, not as much added stability as one might have hoped...)
And with the dawn of widely available LLM / ChatGPT stuff - anyone who types for a living has to rethink how they do what they do.
Anyway, related to the first article's emphasis on young geeks growing up - "an Ode to Grids" - - some truly fun animations in that one. I remember geeking out with graph paper as a high schooler and then even when I got a nice graph paper notebook - playing with 2D and isometric 3D fonts and shapes is tons of fun.
Github blog on keeping up with big shifts in tech. Two of the big takeaways from the participant's history for me were:
1. Object Oriented Program regret
2. But later, regret on not jumping on React sooner.
The anti-OOP feeling reminds me of the classic Object Oriented Programming Oversold! geocities page. In a way that dead page inspires me when I feel like a curmudgeon shaking my fist against a landscape with way too much flavor of the month.
I also feel like a little bit of a hypocrite, I have great stories about my personal projects (especially my porchfest websites) - performant, long-lasting, lots of UX challenges met - but the code base is laughably out of step with what I do for work (and always tempts me to fire up "Taking PHP Seriously" and its descendent posts) - but then I see something like Javascript Gom Jabbar (named after a point scifi torture device) that is a deep dive into the myriad painpoints of a modern JS project's "package.json" and I don't know if I should be grateful that I avoid those pitfalls in most of my projects, or sad that I'm weak and flabby for not having more practice with them outside of a work context.
But the way how two of the respondents regretted avoid React in its early incarnation... interesting. Like, React smelled so much better than Angular, and the idea of declarative programming has such a beauty to it, that I was able to embrace it with few of my normal reservations. (That said, I still prefer to turn to declerative programming in Vanilla JS when I have that kind of problem for side projects, but still...)
Some good advice on first round interview prep and the like. There's a fair amount of legwork you should be considering!
(Also random specific nugget I heard from another successful job seeker - for your LinkedIn headline, play the keyword game. Don't spam it, of course, but put in relevant technologies and skills recruiters will be looking for instead of high level aspirational summaries.)
Also, not unrelated: I've been doing this blogspot based devblog for 12 years - like just over half as long as I've been doing my own blog kirk.is (with its custom homebrew CMS). But Kudos to blogger and blogspot (both of which got start in 1999) on their longevity, even if it all got bought by Google. They've been low key kicking around powering the indie web for almost a quarter of a century! Famously long lived institution Harvard's effort is petering out this summer after only 20 years.
Making the rounds, a really nice deep dive into SVG. It reminds me of the old Logo programming language, where a little turtle (generally virtual but they also had small robots you could buy) would scoot around.
I think SVG expertise is a really interesting boundary of design and dev. A designer might generate an SVG with little idea of how much like a little computer program it is (heh - an svg file is like a computer program as source, a png or jpeg is more like computer program as a binary file.) But a dev often won't have a feel for how that program relates to the curves and lines that went into making it.
(On a more pragmatic note, this article argues for SVG icon sprite sheets as being the best blend of performance and flexibility in React)
A job interview I'm on might touch on Python. I asked ChatGPT to bring me up to speed a bit, knowing that I have good knowledge Javascript and a small pile of other exposures of varying ages and intensity (Java, PHP, Perl, etc)
It mentioned the "Zen of Python" you get when you type `import this` into the Python interpreter:
>>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
I like it a lot, and find it amenable to my views and practice. The main thing I might not get is the last one (well maybe it's the second to last one - there's rumors of an unprinted 20th one which might be a kind of metajoke about not saying too much) - Python has scoping (as does everyone) so it's not clear if it's a call for more explicit namespacing or what.
Interesting hearing about "server side languages for the front end" - especially in proximity of all the hubbub about Server Side Rendering in React and other javascript based languages. (And also how much vitriol javascript inspires in so many full stack folk)
SSR in React feels like teaching the new dog old tricks. And overall the trend to do more server side and ship the HTML over the wire... heh. I remember this one time I stumbled on some little used JQuery syntax that was geared at smoothing replacing part of page content with the HTML from a server query:
$('#someElement').load('url_to_your_server_page');
(Interestingly, GPT 4 knew that command I half-remembered, while GPT 3.5 used more typical ajax commands)
So, like, there's nothing new under the sun! (but there sometimes seems to be a weird acceptance of increasing complexity and size of the cross section of what folks need to know to do their job properly.)
I have a technical interview Monday.
These are so often intimidating, either because they may throw in obscure-ish "gotchas", or just the general issue that 90%+ of, say, React work is done in a context where the basics are setup, and every new component for feature is the appropriate variation of something that already exists. But most tests are throwing you up against something new and closer to greenfield (even they are asking you to "find the mistakes in this code")
Anyway. Sometimes in these cases I like going back to basics, like going through tutorials and hands on stuff so I regain fluency in low level stuff.
The React site has a Tic Tac Toe tutorial. You are given the option of editing it in codesandbox, or from there you can hit "export to zip" and run it locally, which seemed like the richer option to me. But if you do so you are likely to see this error:
./src/App.js
Line 2: 'React' must be in scope when using JSX react/react-in-jsx-scope
The solution is to explicitly import React at the top:
Not sure why the demo there doesn't have/need that.
Also doing a simple "2 player only Tic Tac Toe" game (i.e. no AI to play against) was one of the first programs I remember writing in BASIC on Atari 8bit computers (the 800XL). What's funny is I used the same basic algorithm for detecting if the game was over that the React demo uses (just seeing if any of the square sets representing the 8 possible ways of "winning" the game were filled with the same player's marks.) I remember as precocious...4th grader? 5th grader? explaining that technique to my Aunt, and her saying it was the kind of thing she didn't think that she could come up with. No wonder I was so full of myself as a kid. (Sure, only as a kid)
I play in several activist street bands - BABAM's supply of business cards was running low. The old front design was pretty good, but I revamped the back:
Not quite as cool as my personal cards, with artwork by James Harvey:
