Hi, I'm Dorian.
I like to make things, and I like to make things happen. I'm interested in the intersection of technology, design, and society. I write about products, user experience, entrepreneurship, art, and culture on my website, doriandargan.com. This is where I post some of my inspirations.
Welcome.
twitter.com/doriandargan:
(Answer by Sahana Mysore, Enginerd), link to entire question here.
Teach him skills. Whether you sign him up for a shop class or baking lessons, he’ll learn not only tangible skills (e.g. to use a lathe if it’s a shop class) but also the intangible skills that comprise the maker mentality — estimation (how long should this bake for if my oven always underheats things?), scaling (hmm, what if i want to make 23 cupcakes instead of 11), innovating (i bet this frosting would take yummy with some cinnamon), etc.
Let him spend money. ”Making” has costs. To learn how to sew, you need a needle, thread, some cloth, and if you don’t have any ideas, a template. A lot of parents urge their kids to be resourceful, regardless of the task at hand but this isn’t always most encouraging thing to hear: “Oh you want to build a model rocket with an on-board camera? That sounds cool. You can do it if you buy all the parts yourself.”
Leave him alone. Building, especially at a young age, is a solitary activity. It requires time to think about what you want to build or change and lots of editing, chiseling, re-writing, etc. If your kid’s schedule is jam-packed with all sorts of activities (swim for two hours, then rush to ballet lessons, then eat dinner with family, then homework, then night time art…), he’ll never have the requisite time to do the kind of reflecting that is needed for making things.
Inspire him. Bring home cool stuff (cool for you, not for him) — that sounds vague but my parents always brought home things that they thought were awesome. They would tell me how X was the softest or loudest or sharpest X that existed and why that was important or new or interesting. It wasn’t huge, but it got me thinking…
I thought this was a pretty cool blog post… and seems like an interesting start to a product as well.
Note - I haven’t written for a very long time. If something is wrong, please let me know!
The idea of Oak is something I’ve been thinking about for a long time. Realtime, anonymous communication is something that fascinates me - it’s an uncommon paradigm on the Internet these days. It presents a few interesting questions:
- Can a conversation stay cohesive without knowing the other participants’ identities?
- Is there a way to provide context to a conversation without letting participants’ identities be known?
- What value does divulged identity give to a community?
- How do people act when they feel truly anonymous? Is it a caricature of their behavior, or their true personality?
I will write about these questions later, but this is my story of getting started:
I’ve been thinking about making a realtime forum of sorts for about a year, and I had already gone through several iterations, throwing something together, deciding it wasn’t right, and coldly running an rm -rf *. and I decided I would code something up last weekend. After messing around in Photoshop, I came up with a simple design. I fired up Vim and got to work.
I’m really lucky and I get to use node.js and socket.io every day at work, so I already had the basic structure of the app in my head. I wrote out the routes and views I thought I would need and a couple of hours later I had a functional, realtime shell. I fired up a server with MongoHQ and hooked it up. The time flew by! It was 4am and I crashed, falling asleep with a head full of code.
Making it happen
I woke up Saturday morning excited and ready to get back to work. I set a goal: get this thing working and throw it up on Hacker News by the end of the weekend. I added some niceties like humanized time and a toggle button for the reply form, realtime thread watcher counts, and realtime reply counts. I started sharing the link to my dev server with a few people to get feedback. It was generally good, but people didn’t seem too interested in the idea. I checked the time and it was already midnight! I shrugged off the disinterest and crashed again.
The end of the weekend was coming up, and I didn’t even have my DNS set up. I fixed up some UI elements, added keyboard shortcuts, and made sure it rendered correctly on my iPhone. I fired up a small Joyent server, edited my ssh config, and with a simple git remote add joyent oak:repo && git push joyent master I had the app up in production! I edited the DNS for my domain and shot out the link to a few people. They started posting and the server kept crashing - not a good start. I tailed the log files and found the problem: a single switched character in a variable name. I pushed the fix in about a minute and everything was good.
I threw the link up on Hacker News and waited. People started showing up and clicking around. They were posting and nothing was breaking! I responded to some posts asking what it was, which I found very interesting - people knew how to use my site without even knowing why or what it was.
Then all hell broke loose
In my haste, I had forgotten to poke around the site for security holes. This was my largest mistake. There were XSS holes everywhere. People were able to throw IFrames into the front page, images in titles, and execute JavaScript (that crashed my browser). I scrambled.
My first step was to make a ~10 line tool to delete posts quickly. I pulled the offending posts up in MongoHQ for reference and deleted them from my shell. I figured out how people were able to get around my checks and patched them up, pushed the fix to production, and waited for more to come through - and come through they did. I ended up patching about a dozen holes that people exploited. It was pretty fun looking back on it.
Then, the spam came. I kind of expected it, but not to this extent. Mostly it was harmless fun - “I am a DG”, “I WILL NOT BE BANNED” (they weren’t), and about 500 links to someone’s blog.
I stopped this with two tools:
- I implemented a rudimentary flood check. 15 messages every minute was more than enough for someone using the site correctly.
- I wrote a simple script that allowed me to ban people by their IP, and another that allowed me to simply put in the post ID and it would go out, find the IP, and do the work of the other script.
I had also realized that I forgot to add indexes to Mongo! I ran through the queries I was using, fired up the repl, and added the right ones. The front page sped about about 10x.The site calmed down and most of the spammers were either blocked or left. I was out of the woods.
Design choices
Along the way, I tried to keep my hack as simple as possible. I’m not using a frontend framework, which is a pain in the ass sometimes but has allowed me to fix things very fast and not worry about following someone else’s standards. The code at this point is pretty messy, and not something I would put in production unless it was a side project.
Simplicity in the app manifested itself in a few ways:
- Keyboard shortcuts were crucial - I probably wouldn’t use the site myself without them.
- Everything has a function, even the whitespace. If you click on a post on the front page, it will go to that post. If you click on a reply, you automatically respond.
- There were only three static pages which I had to write: Create a post, About the site, and a 404 page.
- I only wrote markup for WebKit. If somebody is using Internet Explorer, I don’t care if the site breaks for them.
The largest rule I kept for myself was to make no barrier to entry (unless you’re using IE :P). You don’t have to put your name, email, or anything in. In fact, you couldn’t if you wanted to.
Conversely, there is no barrier to exit. If you want to forget about Oak for the rest of your life, there is nothing stopping you. I won’t email you, I won’t notify you on your phone.
Oak is a participatory community.
I think this is imperative for the feel of the website. I don’t want it to feel like I’m taking data from you, because I’m not. I don’t log IPs unless someone posts, I don’t store names or any other personal information about a user. It wouldn’t add anything to the experience.
One of the most interesting phenomena was people creating threads with ideas on how to improve Oak. It implied some sort of care for the site, but perhaps I’m reading too far into it. I implemented a lot of suggestions and fixes throughout the week, and replied to people to thank them for their ideas (though there was no way for them to know it was actually me).
Most people asked for a way to identify themselves so their conversations would be easier to maintain. I saw the logic in this, but I was determined to keep things as anonymous as possible. I ended up talking with a designer friend and he mentioned the site needed more character. ”Color!”, I thought.
The only common denominator between all posts in a session is an IP address. I implemented a simple algorithm to hash IPs, convert the output to hex, and take the first 6 characters. What I’m left with is a color! I stuck these in front of every post and reply, so you can now see the context of identity in a conversation on Oak without actually knowing the identity.
What’s next?
I’ve gotten even more feedback from friends and visitors to the site, and I plan on implementing some of them soon. Some ideas I’m throwing around:
- Threaded replies by indentation
- A right column on the home page to preview a thread before you click
- A “new” feed to watch all posts come through
- Optional, anonymous accounts for a permanent identity on the site
- Open sourcing the code
Even if I implement any of this, I’m going to stick to keeping this thing simple. I think it shows promise, though I’m not sure what that promise is right now.
Over the next few weeks, I’m planning on writing more about my experience making Oak and what I’ve learned from it. If you’ve read this far, thank you! You can get in touch with me over Twitter, I’d love any feedback you have!
(Source: oakio)
