I once watched a TED talk where the speaker was discussing the fact that generally, we approach things the wrong way when we communicate. We will tell others about what we are doing. We will tell them about how we are doing it. The thing which we do not do enough, though, is talk about why we are doing those things. I thought it might help everyone to understand me, and where I come from, a little better if I told you about my whys.
Why do I work on the web?
The Internet connects us in a truly unique way. It’s like a technological worm hole. Suddenly, because of the Internet, the distance between any two points becomes almost negligible. In a world where we measure commutes in minutes, hours, or sometimes days and weeks, the subtle difference between 50ms to a local point and 200ms to Bangladesh seems quite trivial. It connects us, across the globe. The web, then, takes our new connected society and gives it a (mostly) unified way to read, create, and share. And boy do we love to share. We love to share videos. We love to share music. We love to share cats, and babies. We especially love to share cats and babies with little witty sayings stamped out on top of them. The thing we love to share the most, though, is ideas. Sometimes those ideas are bad, sometimes they’re hateful, sometimes they’re beautiful, sometimes they’re funny, and sometimes, every once in a while, they’re magic.
Why do I care about building software?
Software has the unique power to change how we, as humans, interact with the world. Software, of course combined with the hardware it enables, allows us, as a people, to affect the world in amazing new ways. Whether you are writing code for a bank that helps ensure money transfers work efficiently, writing for a startup who has found a new way to deliver cheese, or writing software that enables better communication in third world countries: you are changing the world.
When you learn to program computers, you are teaching yourself that nothing is as it appears. Everything is moldable, variable, able to be adapted and adjusted. Fluid. You stop seeing the world as a finite set of things, and start to see it as a current, but changeable state. The world is a set of problems that has yet to be solved, and I want to help solve them. However, I can’t do it alone, there’s just far too much work. I need help. I cannot do it alone.
Why do I place so much value on community?
I see community as the heart of software, really. Everything we do is iterative. Everything we do today is built on the shoulders of giants which came before us. Everything the next generation of software workers will do will be built upon our giants’ shoulders. However, most often, giants do not grow in isolation. The giants I speak of, to be clear, are ideas, not people. Mostly small, many trivial, but ideas none the less. Inside each one of us is a giant, waiting to come into being. It just takes the right set of circumstances, the right set of knowledge, the right environment, to bring them to life.
I see community as a way to feed those budding giants. I see community as way to take a junior developer, show them the ropes, show them how … squishy … the world actually is, and seed them with passion. I see community as a way to take mid-level developers and fuel their passion with ideas. Finally, I see community as a way to take senior developers and give them an outlet where they can refine their ideas, vet them with peers, and share them back to the community, fostering growth and innovation, spurring more passion and ideas.
I love PHP for so many reasons, but the reason I love it most in this context is because I consider PHP the “starter drug” of web development. Open almost any basic shared hosting account, upload an index.php file, and you’ve just taken your first step towards changing the world. Within the PHP community, we have the unique opportunity to catch these new developers just as they’re dipping their toes in the lake. It is incumbent upon us to welcome them, teach them how to swim, and more importantly, show them how to teach themselves to swim better. Faster. Farther. Even more, we can show them passion. Passion isn’t unique to PHP, but our proximity to those who don’t yet know that it exists is.
Why any of this is relevant?
I have an overwhelming desire to do. To create. To build. To teach. To do. But I want to do so many things, I’ll never get any meaningful amount of them done. The only way I am ever going to make any dent in my to-do list is to get some help. I’ll need more than some help, though. I’ll need an army. An army of ruthlessly competent individuals who believe they can change the world. An army who believes they will change the world. An army equipped with budding giants, prepared to tackle anything. Software is the great equalizer. Anything is possible. The solution may not be cheap, or the solution may not be practical, but there is always a solution.
Stay tuned for more! In the next installment of “The why of the thing” I will detail my ideas on how to build this army of ruthlessly competent individuals, and how that differs from the way we teach people how to program today.
Back in 2013, I gave a brief talk at php[tek] which was about all of the things you need to learn along the way to be a developer. I promised I would put up the list from my notes — and as you can see from the date, I pretty much failed on that promise. However! I found the notes! So without further adu…
- Broaden your general PHP knowledge
- PSR-0 (and other PHP-FIG initiatives)
- Code versioning (Git, SVN, anything…)
- Dependency Managers (Composer!)
- Design Patterns
- Unit testing
- Basics of encryption
- Public and private key encryption specifically
- Code smells
- HTML & CSS
- UI integration tests
- Learn about build automation tools (phing, make, ant, jenkins, travis)
- Learn about deployment automation (capistrano, dploy.io, etc…)
- Pick up some solid Linux administration skills
- Code smells (MOAR!)
- Pick up more languages
- More design patterns
- More code smells
- Better your testing approach
- Programming styles
- Object Oriented
- Event Driven
- Build on a new type of platform (notice the “web” in “Web Developer” went away up there?)
- Build a desktop, or mobile app.
- Build a server daemon.
- Build command line tools.
- Learn to do Security Model assessment
- Pick a new thing to learn, and learn it!
- Teach others what you just learned
- GOTO 1
So it’s time we made a real push to connecting more with the members of the San Francisco PHP User Group. To that end, step one for any web-savvy group is always a website!
I want to get a website built for SF PHP to allow us to better support and engage the PHP community: both the developers and engineers (however you wish to label yourselves) working in it, and the companies relying on it. I want to connect those two groups in meaningful ways to help promote the adoption, growth, and sustainability of PHP in the Bay Area, and beyond.
The purpose of the project I am looking at, at the moment, is to get the ground work in place. We need a basic site with a simple CMS system at first, but I want to add a lot of functionality to it eventually — incorporating logging in via the Meetup.com API, talk archive, videos on the site, articles by local developers, technology articles by local php companies, eventually hooking into a custom sf php mobile app for the meetups themselves – so I think starting from a custom stack is the way to go.
Secondarily, I would like the core group that builds the initial prototype do a dual-purpose meetup (perhaps in series, however it works out) which will both cover “introduction to Zend Framework 2” and “Here’s how you hack on our site to add new features.” There’s a bit more I’m trying to work out with this, but I don’t want to say anything publicly until I know for sure.
I’m not super married to anything design wise, just trying to get some of the structure in place.
That center bit will either show:
– Next meetup
– Live meetup stream if a meetup is currently happening and has a live stream available
– The last meetup’s video
– Recent articles if there’s a given amount of time between the last meetup and the next one. Perhaps at that point we would put the last meetup’s video where the speaker bio is and have the recent articles in the zone on the left.
Basing it off of bootstrap or foundation would let us iterate faster in the group, I suspect, but I don’t necessarily have a preference.
So one of the things I have been seeing more and more are meat-space kiosks that are enabling (and encouraging) you to interact with them by sharing the activities you participated in via your social media identities.
How are they doing this? By having you type your credentials directly into the kiosk. Not only is this a Really Bad Idea(tm) but even the act of encouraging the generally non-security-savvy population that this is a “thing” is horrifically scary. No longer do you need to click on a phishing email to lose your password, all you have to do is buy something from a kiosk which has this configuration in it, from a kiosk which has been hacked. Oh wait, it’s not like that ever happens, right? Certainly Target would never get hacked, and if Target is safe, well, maybe the little guys will be fine too.
This is a patently Really Bad Idea but I don’t think it’s going away, so what I propose is this: sites and services that consider themselves identity providers (a.k.a. you offer OAuth login credential verification for third party sites/apps/projects/whatever), with their mobile app, should provide an easy way to generate a limited-time-use OAuth token, and then provide a way to display it via QR code, or similar.
Granted, this would require adding a webcam to the kiosks, but webcams are dirt cheap, and the net positive for everyone involved. Heck, I bet it turns out to be so much more user friendly that the rates of those social participation options becomes more frequent. Imagine Retailers could even, with this new, nearly painless, option, even offer users a chance to tweet, or post a status, about their in-progress transaction to receive some sort of discount, or special offer.
Bottom line: let’s get real and not encourage the general population to foster insecure password management choices. Entering your password (which is statistically likely your password to everything) into a public kiosk which exists in an unknown state of security is a bad idea, every time. Making it normal is an even worse idea. Let’s wrangle this under control before it becomes even more wide spread.