Next Tuesday, April 2nd at 6:15 p.m. Central / 7:15 p.m. Eastern / 23:15 UTC, I’ll lead an online introductory session for people who to dive into AI titled AI: How to Jump In Right Away.
My session is part of Austin Forum on Technology and Society’s third annual AI April, a month of presentations, events, and podcasts dedicated to AI capabilities, applications, future impacts, challenges, and more.
My presentation will start with a brief history of AI, as well as the general principles of how “old school” AI works versus “new school” AI…
…but we’ll quickly dive into building Sweater or No, a quick little AI application that tells you if you should wear a sweater, based on your current location. Here’s a screenshot of some of the code we’ll build:
This is a FREE online session, so you don’t have to be in Austin to participate. I’m not in Austin, but Tampa Bay, and you can join in from anywhere!
A hackathon is a competitive event where people with a technology bent — typically developers, designers, and other tech enthusiasts — form teams that work to build a software prototype (which can also include some hardware) that solves a problem or accomplishes a goal within a limited amount of time (typically ranging from a few hours to a couple of days).
Think of it as a pressure cooker of skill and creativity, where teams of participants brainstorm, code, design, test, and refine their creations in a race against the clock — and other teams! Collaboration and innovation are key, as participants huddle around laptops, sketch pads, and whiteboards, exchanging ideas, troubleshooting, and iterating rapidly to refine their solutions. Mentors and industry experts are often available to provide guidance and feedback, adding another layer of learning and networking to the experience. At the end of the event, teams present their projects to a panel of judges or the entire audience, showcasing their ingenuity, technical prowess, and presentation and problem-solving skills.
To use the words of the organizers, Tampa Devs, “It’s one part party, one part work-your-butt-off overnight battle against the clock and the competition.”
What will participants be building at BayHacks 2024?
This hackathon doesn’t have a theme, so participants can build any kind of software/hardware project they want.
However, they don’t have a lot of time to build. Building time starts at 12 noon on Saturday and stops at 2:00 p.m. on Sunday, followed by project presentations, judging, and the awarding of prizes.
Do I have to participate, or can I just be a spectator?
Space is limited, so there isn’t room for spectators. If you attend, you must participate in a project!
Opening ceremonies, explanation of format, and other announcements
11:00 a.m.
Team formation
11:30 a.m.
Pitching proposals
12:00 p.m.
The work begins!
5:00 p.m.
You don’t have to stop, but you have to exit the venue.
Sunday, February 25th
Time
What”s happening
10:00 a.m.
Participant check-in
10:30 a.m.
The work continues!
2:00 p.m.
Teams present their projects
3:00 p.m.
Judging and the awarding of prizes
5:00 p.m.
End of the event
Did you mention prizes?
Yes, there are prizes. Cash prizes, in fact…
Place
Cash prize amount
1st
$750
2nd
$500
3rd
$250
How are projects judged?
They’ll be judged on the following criteria:
Quality and innovative nature of the idea / demo
Utility of the idea / demo
UI / UX design
Who are the judges?
They’re prominent members of the Tampa Bay tech community held in high esteem. You may recognize one of them:
That’s right, I’m a judge. So impress me!
How do you register for BayHacks 2024?
Register for BayHacks 2024 at the BayHacks 2024 Eventbrite page. It costs $10 to register, but that $10 helps cover the costs of running the hackathon and also gets you the official T-shirt, swag bag, andSpa a single entry into the pre-event raffle for a pair of Tampa Bay Lightning tickets.
It’s only day one of the new year and I just fulfilled one of my resolutions: to land a conference speaking session on AI outside my usual stomping grounds. I’m going to be a speaker at Civo Navigate North America, which takes place on February 20th and 21st in Austin, Texas!
What’s Civo Navigate, and what is Civo?
What’s Civo Navigate, you ask? Here’s a one-minute video that answers your question:
Civo is a cloud hosting provider based on Kubernetes, with a focus on developer-friendliness and wallet-friendliness. It’s a refreshing change from this state of affairs:
I met the people at Civo last year when they held Civo Navigate North America in Tampa — and not in a convention center or hotel conference rooms, but at Tampa’s big riverside food hall, Armature Works! Here’s the promo for that event:
The 2023 edition of Civo Navigate North America was a great conference with interesting talks and a warmer, more personal “feel” than a typical vendor-hosted event. Civo’s contributions continued long afterward, with their being great supporters of the Tampa Bay tech scene and this blog.
I’m looking forward to the 2024 edition in Austin?
What’s my talk about?
My talk is titled You’re not too late to the A.I. party, and it’s for people who’ve been too busy with their actual work to get into AI and have been feeling increasing amounts of FOMO.
Here’s the description of the talk, with additional AI-generated photos (that are deep in the uncanny valley):
Have you been too busy getting your actual work done to join the artificial intelligence party and feel that you’ve already missed out on the technical career opportunity of a lifetime? If you answered “yes,” this talk is for you.
The good news is that you’re not too late to the A.I. party. It’s just getting started and you arrived at a good time — perhaps even “fashionably late!” You just need someone to take you around the room and make some introductions.
To help you “work the room” as you enter the party, you’ll get an overview of artificial intelligence technologies, from the rules-based models and expert systems of A.I.’s early days to the present era of neural networks, machine learning, transformers, and large language models.
This party won’t be limited to just hand-waving small talk in the living room. We’ll go into the kitchen — the true heart of any party — and look at actual code in action. We’ll start with ELIZA, the original chatbot from the 1960s, observe a neural network, and look at an LLM-powered “What should I wear today?” app. You’ll even be able to download them for yourself!
This talk aims to be like the best parties — the ones you’re glad you were at. You’ll leave this one knowing more about AI’s underpinnings and a much better idea of the next steps in your AI journey, whether it’s catching up with AI developments, harnessing your current skills to integrate AI into your work, or even pivoting into AI development.
In my talk, I’ll discuss:
Generative vs discriminative AI
“Old School” rules-based AI vs. the “New School” version powered by neural networks, data science, and lots of data
How the internet changed AI
The intersection of data science, statistics, and AI
The paper “Attention is All You Need,” what it means, and how it changed AI forever
Large language models (LLMs)
Retrieval-Augmented Generation (RAG)
Vector databases
This talk won’t be all hand-wavey and descriptions, but will also feature demos of actual working code that you can also download, including:
ELIZA, the original 1964 chatbot, but written in present-day Python.
A basic neural network demo that shows how you implement them — perhaps the one that recognizes handwritten numbers, perhaps something a little more interesting!
“Sweater or no?” — a large language model-powered application that tells you what to wear based on your location, the weather, and the event you’re attending.
I’ll also talk about potential “next steps” that you can take, including:
Reading material, including the funniest book about AI (for now): Janelle Shane’s You Look Like a Thing and I Love You. Of course, you don’t have to wait for the talk (or even attend) to read it; you can get it now!
There Will Be Math — or, the math you’ll need to know to get into AI.
Effective Altruists, Effective Accelerationists, and how to Effectively Avoid both.
How to send the right signals to employers so they’ll know that AI is your jam!
I’d been meaning to get one for some time. There was a deal on them last weekend, so I placed an order for the PyGamer Starter Kit, which included all the goodies pictured above.
The PyGamer is a cute little unit that doesn’t take up very much space, as the photo below (shown beside a U.S. dollar bill and quarter for scale) shows:
Here’s a close-up photo of the front of the circuit board. That’s an analog joystick on the left, the screen in the middle, the “A” and “B” buttons on the right, and the “Select” and “Start” buttons along the bottom, with a row of five LED lights between them:
Here’s the back of the circuit board. The most prominent features are the processor (the square thing in the center of the board), the two sockets to either side of the processor, which allow you to connect the unit to FeatherWing daughterboards for all sorts of hardware projects, and the three STEMMA connectors at the bottom, which make it easy to connect the unit to all sorts of sensors and devices:
The Starter Kit comes with pre-cut acrylic pieces that form a protective shell for the unit, plastic caps for the buttons, a speaker for game sounds, a rechargeable battery, and a carrying case. Here’s what the PyGamer looks like with the enclosure assembled:
What are its specs?
At the heart of the PyGamer is the ATSAMD51, a microcontroller built on the ARM Cortex M4 processor, which is used as the basis for a lot of chips for small devices or embedded controllers. Released in 2018, the ATSAMD51 is a 32-bit chip running at 120 MHz with 512K Flash memory and 192K of RAM. It’s not going to compete with a Raspberry Pi, but it’s more than enough for handheld retro-gaming.
The PyGamer board housing the processor provides these goodies:
An additional 8 MB of Flash memory for files, which is meant for game assets: images, sounds, fonts, and other data.
A MicroSD card slot for even more Flash memory.
A backlit 160 by 128-pixel color TFT display.
An analog thumb joystick, a scaled-down version of the ones you’ll find on PlayStation and Xbox controllers.
4 buttons — the classic “A,” “B,” “Start,” and “Select.”
5 Neopixel LEDs, whose colors can be individually controlled. These can be used for additional feedback, such as showing the user how many “lives” they have.
A 3-axis accelerometer for sensing motion.
A light sensor.
A headphone jack as well as a speaker driver. The PyGamer Starter Kit includes a speaker that plugs into the driver for headphone-free sound.
How do you program it?
The easiest way to program it is via MakeCode Arcade, a friendly programming tool that allows you to create games using drag-and-drop blocks like Scratch. It also supports game programming in JavaScript or Python with its game libraries.
Want to get a little more hardcore with the programming? It’s also programmable in CircuitPython, a version of Python made specifically for microcontroller boards.
For fun, of course — but also for sharpening my programming and hardware skills while having fun! In today’s world of laptops, virtual machines, and a zillion abstractions that distance programmers from their systems’ “bare metal,” having a low-level understanding of computers is an increasingly rare skill. As always, I’m trying to set myself apart.
I’ll also use it in an upcoming video series on programming — watch this space in 2024 for more!
On Tuesday, Venkat Subramaniam, author of a lot of great books, including the award-winning Practices of an Agile Developer, gave yet another one of his insightful, informing, and entertaining presentations at the joint meetup run by three of Tampa’s big tech meetup groups, Tampa Bay Techies, Tampa Devs, and Tampa Java User Group.
When I arrived at the venue, Kforce’s office — Tampa’s cushiest meetup venue — the cafeteria area just outside the presentation room was already packed.
In moving from Toronto to Tampa — ten years ago in March! — I had to get rid of most of my books, keeping only those that had either great meaning or great usefulness.
One of those books that I held onto was the first edition of Subramaniam’s Practices of an Agile Developer (there’ve been six editions in total).
So I did the natural thing: I brought it to the meetup so that I could get it autographed!
I love the photo above, which Ammar Yusuf took. It looks like a Bollywood buddy film!
The book was published in 2006, and even after all this time, a lot of it is still applicable, thanks to the book’s emphasis not on technology, but on people and practices. If you’re a software developer or manage them, you should read it!
I have never seen a meetup where not only every seat in Kforce’s presentation room was filled, but where they brought in additional seats, and the remainder gathered by the entrance.
It was great to see so many people from our developer community come out, as well as to see a great programmer, author, and presenter give a solid and entertaining presentation.
My thanks to Venkat Subramaniam for presenting, Kforce for hosting, and the organizers:
There are things I thought I knew that are no longer valid
We need to constantly re-check our assertions and assumptions
When building software, we need to consider:
Functional requirements, which stakeholders are quite focused on
We also need to spend time on non-functional requirements, such as performance and security
There are a number of “ities” that we need to consider:
Scalability
Interoperability
Deployability
Configurability
Security
Accessibility (which we really need to pay more attention to)
The answer to “What’s important?” can’t be “everything”
Where’s the line between architecture and design?
Design decision changes hurt a little
Architectural decision changes can hurt a lot more
What are the characteristics of good design?
Consider the case of extensibility:
It’s a slippery slope
So much code has been written in the name of extensibility
I remember once writing code that modeled chemical reactions and thought I would extend it. The chemists who I worked with said that they only work with hydrocarbons, and those molecules would never behave in the ways my software would support
Extensibility requires the ability to anticipate really well
If we anticipate really well, we get extensibility
If we do it poorly, we get unnecessary complexity
Code is like a crowded train — the more people on the train, the harder it is to get in and move around
These days, I say wait until you see evidence of a need to change something before thinking too much about extensibility
Reusability
Grady Booch says to make the code usable first, then think about reusability
Cohesion: code is narrow, focused, and does one thing really well
Like things are together, unlike things are apart
If you use design principles, try to keep in mind what value they provide
I found a sock and fork on a table. What questions would you ask about this?
What if I told you that the table was in a museum?
The lesson is that context matters
What may be right in a certain time may not be right in another
There is no one cohesion in general
We do two kinds of partitioning all the time
Technology-based partitioning
Domain-based partitioning
Which one is predominant?
Most of us have been doing technology-based partitioning — it’s where we spend a lot of time and effort
Think of talking to a bank executive and saying that you’re building a client-server system — they’ll be confused, because as far as bankers are concerned, clients are customers
We have teams built around technology-based partitioning: “front-end developer, back-end developer, Angular developer,” and so on
In one example, I talked to a developer working for a bank who said they were on the front-end team. When I asked about making changes, they said “that’s back-end; you have to talk to them.” This is technology-based partitioning.
At another bank, I talked to another developer who said they were on the “move money” team. When I asked about making changes, they said “talk to my teammate”. This is domain-based partitioning.
If you build the team around the technology, they will focus on the technology
If you build the team around the domain, they will focus on the product
Monoliths: We often focus on technology-based partitioning
Microservice: We often (or should) focus on domain-based partitioning
Client-server: You’re optimizing for technology
Microservices: You’re optimizing for domain
In talking to people building microservices, I ask “Why?”
The answer should be “In order to provide business agility”
YAGNI
Don’t write anything until you really need it
There’s a balance between YAGNI and extensibility
Do what you know is needed
DRY
The general idea is that every piece of knowledge should have a single, unambiguous, authoritative source of representation
It’s about removing of duplication of effort, not just duplication of code
I once consulted with a place that had a database where the tables had something on the order of 800 columns
Every application in the enterprise uses that database!
It’s DRY
Focus: Stability, not agility
Changing the schema will break a lot of apps
File change request — where progress goes to die
Two things in life and programming that I will never share:
Toothbrush
Database — Sharing a database loses encapsulation
The higher the encapsulation, the higher the business agility
We want low coupling and loose coupling
Do we want reuse?
Answer is typically yes
Do we want to reduce coupling?
Also yes
Increase reuse: increase coupling
Reduce coupling: increase duplication and reduce reuse
Microservces tenets:
1. Encapsulation
2. Autonomy of development
3. Isolation of deployment — how do we provide?
Performance
The most important question: Not if the speed is great, but is the performance adequate?
The end result of worrying about performance is the worry, not the performance
Do microservices provide excellent performance?
No
They’re distributed across multiple services
If you want more scalability, you have to reduce performance
If you want more performance, you have to reduce scalability
To fail 100%, be absolute in your demands
Distributed transactions are so 20th century
They’re an interesting technical idea — zero practical
Technical transactions have to be extremely short-lived
Two things are figments of the imagination for programmers:
Transactions
Concurrency
Please never ask your business analyst/people: “Is consistency important?”
You can’t provide all three of these at the same time
(Strict) Consistency
Availability
Partition tolerance
If we work hard to deliver what’s not necessary, we miss out on the truly necessary things
Architecting is an act of evaluating trade-offs
Worth watching
Following his theme of evaluating trade-offs, Decision Dials is a talk of Subramaniam’s from Devoxx UK earlier this year. It looks at the art of decision making, the consequences of the choices we make, and how they tie that into the everyday architecture and design of enterprise systems.
Back in June, I posed a question on this blog: Would you like to know how computers REALLY work “under the hood?” Tampa Devs, a very active nonprofit with a mission to support the local developer community though this would be a good presentation topic. On Wednesday, I gave that presentation to this crowd:
I started by telling the attendees that while knowing about microprocessors and assembly language isn’t absolutely necessary to function in a lot of developer and tech jobs today, there’s value in that knowledge:
I talked about transistors…
…made note of the fact that it was the 52nd birthday of the commercial microprocessor…
…introduced the 6502…
…got deeper into its inner workings…
…and then we dove into 6502 assembly language programming!
Tampa Devs recorded the entire thing, and you can watch it here:
All the material from the presentation is available online:
Tampa Devs for inviting me to speak at their meetup — it’s always an honor and a pleasure to work with a group that contributes so much to the Tampa Bay tech scene!
Kforce for providing the venue, which I like to say has “the comfiest meetup chairs in Tampa Bay.”
Civo for sponsoring the pizza, sodas, and water for the attendees, and taking such an interest in supporting the Tampa Bay tech scene.