Archive for the ‘Misc’ Category
I know everyone has posted a list of the best/must-have iPhone apps. I am sure many people have also posted lists of Apps they would like to have, but it is amazingly fun so I decided I should do it to.
This is my list of apps and solutions I want for the iPhone. They don’t have to all necessarily be native apps. If you know of an web-app (that works on the iPhone) which provides the functionality I am looking for, let me know.
I want something like Brain Age for the GameBoy on the iPhone. Spending a few minutes doing little puzzles and math when I have downtime seems like a better use of my time then just playing random games. I have Brain Tuner, which is nice, but I want some more options/different puzzles.
I want a Google Contacts to Apple contacts one-time syncer, All my iPhone contacts are missing their emails. All my Gmail contacts are missing their phone numbers, someone help me sync that up.
I want full syncing between my Google calendar and the native apple calendar app. I always had this and it was really easy to do on pocket PC. I want a full 2 way sync. Google and Apple seem pretty buddy buddy, so get on this.
I want flash cards, with prebuilt decks. I would like to be able to work my way through some word decks building my vocabulary. I also would love to have some Spanish/English decks. I am working on improving my Spanish by listening to Coffee Break Spanish, and having a Spanish study deck would be great.
I want an EBook reader – oh wait, someone just pointed one out to me (thanks Matt) it is called Stanza. It’s seriously awesome, if they add a screen reader, it would be perfect. I could listen to some classics books while jogging/driving.
I want GPS tracking that works. I have a great iPhone app called Trailguru, which tracks movement/location with GPS and can tell me the speed and total distance I go when I run. The problem is my GPS seems to stop working after a day or two, and won’t come back until I restart the iPhone or re-sync. Then I want a driving direction helper, something that says out loud, “turn approaching in 200 feet,” just like every in-car navigation system.
I want an on-the-go web reader (Ben shared this idea with me). This would offer a way to open/transfer all the tabs or URLs currently in my browser over to the iPhone. Preferably, it would open them all in an offline mode allowing me to then read the articles through out my day, while being on the move. I really would like if this wasn’t even in Safari since that crashes the iPhone too often.
I want a full Flash player, or at the very least the ability to play Flash videos. There are so many sites with Flash videos and streaming video that are useless on the iPhone. I really wanted to watch the debates on my iPhone because I had to leave in the middle, but while every site on the internet was streaming the debates, not one of them had a way to view the debate on an iPhone. Apparently Adobe has confirmed working on Flash, but Apple is likely to block it. Screw you Apple, even Pocket PC phones years ago had Flash.
I want streaming internet radio. Yes, Pandora and a few others are nice, but why can’t I just browse and listen to any streaming net radio station? It would be even better if it could allow me to browse many of the well known stations (shoutcast), with out having to search through iPhone’s browser.
I want something similar to Elasticfox for managing and monitoring EC2 instances on the iPhone. Actually beyond that it would be cool to be able to manage a few scripts and SSH credentials on a site. It wouldn’t allow arbitrary SSH, but you could store ssh login keys and a few scripts it could run and return the results. This would allow you to ahead of time write some scripts to monitor, clean up, restart or do other tasks, which you could then execute and verify the results of remotely over your iPhone. A sysadmin’s dream, until then I have pTerm for slow clumsy SSH.
That is all I have for now, but if you have thought of iPhone apps you would like to have leave some comments. If you know of a solution to any of the problems I mention above let me know. Some of these apps I would be willing to pay for so developers get busy.
Boulder has a lot going on in terms of tech startups. A bunch of Boulder startups got together for a pretty interesting plan. A group of startups will be flying 100 interviewees out to Boulder to interview potential employees and let them get a feel for the city. There has already been some pretty good coverage of the plan on TechCrunch and elsewhere.
So if you are interested in getting a great job with some of the awesome startups in Boulder, I highly recommend checking out and applying to Boulder.Me.
During my search for my first “real” computer science job during my senior year of college, I compared a lot of factors for various jobs including city, company, project, salary, and benefits. The salary stuff was fun to think about (especially after four years of being a poor college student) and I was looking to move to a bigger city somewhere outside of the Midwest (after growing up and going to college there). But mostly I thought about the company and project. Which companies would I want to work for? What project would interest me the most? Where would I learn the coolest stuff?
In hindsight, I realize I’d overlooked the single most important question – is this company going to own my ideas?
I never even thought to ask my prospective employers about their policies on IP and moonlighting. It wasn’t until I’d accepted an offer and received their legal documents that it dawned on me. And even then, I didn’t mind. I thought it was just standard practice and I really didn’t have much of choice*.
For those of you that don’t know, many large software companies technically own everything you think of while you’re working for them. No, not just the stuff that you do at work. They also own the stuff that you do at home, after hours. There is no clean separation of “work” and “personal” projects.
This manifests itself in a few ways. First of all, you may notice that the company explicitly bans working on open-source projects. Or they may require you get explicit permission for “moonlighting” i.e. working on non-work-related projects after hours.
At the very least, you should ask any potential employer about their IP policy before you accept a job. You may be able to get them to loosen their restrictions, especially if they really want you (I haven’t personally done this and I’m not sure if the bigger companies would go for it, but it’s worth a shot).
In fact, I’d argue that you should not accept any job that claims ownership over your outside-of-work ideas – even if that means compromising salary, benefits, project, company, or location. The benefits of owning your ideas are just too numerous and important.
Side projects make you a better programmer. I don’t care if you’re contributing to open-source projects, building a for-profit website, or just toying with a personal project in your own time, writing code that doesn’t relate to work will expand your skills and make you a better programmer at work.
Side projects help your career. Working on projects that anyone can examine are much more valuable than a good resume or recommendation.
As Paul Graham writes in Hackers and Painters:
It seems surprising to me that any employer would be reluctant to let hackers work on open-source projects. At Viaweb, we would have been reluctant to hire anyone who didn’t. When we interviewed programmers, the main thing we cared about was what kind of software they wrote in their spare time. You can’t do anything really well unless you love it, and if you love to hack you’ll inevitably be working on projects of your own.
Your side projects won’t just help you during your next active job search. They form a sort of passive job search in which you’re letting the outside world know how awesome you are. If a better offer comes along, great. Even if you’re happy where you are, you can use external offers as leverage with your current employer (and not just for salary, either. A higher profile outside the company may convince your boss to give you more responsibility at work, publish whitepapers, or attend more conferences).
You can start your own company. If you own your own ideas, then when that little site you built in a weekend starts getting a bajillion visitors a day – you’re free to pursue it. Hello, no boss/early retirement**.
Even if you quit and your startup fails, your career will probably be better off anyway. In Hiring is Obsolete, Paul Graham writes:
Even if your startup does tank, you won’t harm your prospects with employers. To make sure I asked some friends who work for big companies. I asked managers at Yahoo, Google, Amazon, Cisco and Microsoft how they’d feel about two candidates, both 24, with equal ability, one who’d tried to start a startup that tanked, and another who’d spent the two years since college working as a developer at a big company. Every one responded that they’d prefer the guy who’d tried to start his own company.
If you’re trying to rationalize taking that more restrictive job anyway (I mean, they’ve give you free soda at work!), you might be thinking:
“I don’t want to do a startup anyway.” Well, OK. But are you sure you’ll feel the same way in a year? In any case, working on side projects is good for your career, even if you never do a startup.
“No one will know.” Maybe you’re thinking that when you have that good idea for a startup, you’ll just keep it in your head until you quit. There’s a couple of problems with that. First, you won’t really understand your idea until you start working on it. Secondly, some of the best startup ideas come from projects that didn’t initially have any commercial value (and therefore wouldn’t appear to be worth quitting to pursue)
“They won’t be able to enforce it.” You mileage may vary by state (I’m no lawyer, but I vaguely understand the California courts may be ruling against companies in these kinds of disputes), but it probably won’t matter anyway. Since you don’t want to spend time tied up in court, just the threat that your company could come after you will prevent you from working on most ideas. And even if you have a great idea and decide to go for it – do you really think future business partners and investors will want to hear that your old company might own the core IP of your company?
“My new employer lets me list the IP I own before I joined the company, so what’s the big deal?” The big deal is that you’re almost certainly going to think of new (and likely better) ideas during the time you’re employed at the company. Do you really think all your future ideas will fall into the narrow set of things you’ve thought of before you join? Doubtful.
If you feel you like have to take the job (or you’ve already done so), make sure to get permission in writing before starting to work on your new idea. But of course, just the hassle of getting permission is a strong disincentive to not work on your idea at all.
“All CS jobs are going to require me to sign away my IP” On the contrary, many jobs will let you keep your IP – especially if you are doing programming for a company that doesn’t consider delivering software to be it’s core business. Clearly some jobs let you do other stuff – or no one would be contributing to open source. For instance, Matt Mullenweg got to hack on WordPress while he was working on blogs and new media for CNET (in fact, working on WordPress was part of his job, which is extra cool but probably harder to accomplish).
In order to own your ideas, you may have to sacrifice other aspects of your job (not work at a “brand name” company, work on more mundane projects at work***, make less money), but I’d argue that it’s worth it, especially at the beginning of your career. It’s just too limiting to give away that much of your potential – because you never know where the next idea will take you.
*I ended up accepting the job at Microsoft. For the record, I really loved parts of the job (but also wish I could have worked on open source). I hear they have relaxed their policies since I left, which is definitely a good thing.
** For the record, I am not advocating taking ideas from work (the stuff you are being paid to work on) and starting a company based on that (or, for that matter, putting those ideas into open-source code). That’s illegal and immoral. I’m referring to the case where you’re working on X at work – but you want to keep your options open to do a startup that does Y.
*** Being less satisfied at work might actually be a good thing if you are interested in eventually doing a startup, since it will increase the chance that you’ll work on something really cool in your free time.
When I first started working with Ruby I used RadRails (which still has the best integrated test runner I have used). Various problems and crashes with RadRails along with exciting features being added to Ruby NetBeans enticed me to switch. I enjoyed NetBeans and some of its features, but the weight of my IDE began slowing me down. I didn’t have the control to tell it not to do some things that annoyed me.
My cofounder Ben had been using Emacs since learning Ruby. The quick speed that he could work with code, made me wonder what features I was actually using in my bloated IDE. It turned out that I had been getting annoyed with most of the advanced features because they stalled my system, crashed occasionally, or really weren’t that useful. An example of a cool feature that I hardly found useful would be Netbean’s Ruby code completion. In the past I had used Emacs to develop all my C and C++ code and I always liked it, so I decided to switch away from NetBeans and see how Emacs would hold up as my editor.
I have enjoyed using Emacs and think that I can more quickly work with code with far less hassle and frustration. I don’t expect to move back to a large IDE anytime soon. That being said there are definitely pros and cons to working with a full IDE vs an editor, and I find myself missing features sometimes. So I thought I would list out some of the pros and cons so others can weigh these issues themselves.
Reasons I miss NetBeans:
- Graphical test integration linking to the lines of code in the stack trace
- Navigate -> ‘Go to Declaration’, ‘Go to Test’, ‘Go to Action or View’
- Easy code refactoring and renaming
- Code completion, occasionally (e.g. was the Array function called include? or includes?)
- File browsing with folder tree view
- Graphical SVN browsing, easy branch, merge, get version, diff
- Easy project file search (Yes, you can do, ‘grep -Ri ‘Logger’ lib/* bin/* app/* | grep -v .svn’, but that is a pain to type)
- Easy code commenting (Apple-/ which toggles, is much nicer than Ctrl-x, Ctrl-m comment-region / uncomment-region which has to be added to your Emacs configuration)
- Easy code formatting (Apple-shift-f, is easier than Ctrl-x, Ctrl-m indent-buffer / indent-region)
Reasons I hate NetBeans:
- Frequently stalls (Especially if you have been out of the application for awhile)
- Crashes (At least every couple days)
- Not enough user control (stop indexing everything)
- Magic behind the scenes (constantly connecting to SVN every time I saved a file)
- Debugger didn’t work well (ended up running on the command line to get debugging)
- Ruby Console didn’t work well (ended up using irb on the command line instead)
- All tasks that NetBeans handles nicely for you like testing or migrations were slower (ended up running all rake task and tests on the command line)
- Resource hog, making everything else I am running far slower
- NetBeans ignores canceling tasks and continues trying to run them
- Booting up takes a few minute before NetBeans completes its various start-up tasks (You can work during some of the start-up tasks, but it is slow and unresponsive until it has completed the tasks)
Things I like about Emacs:
- Better/more key commands (I love kill/yank – the ability to kill until the end of line is incredibly useful)
- Incredibly fast, if I am working live with someone I can jump in make an edit and be back live showing them the change on the project (Imagine having to boot NetBeans to do this)
- Multiple copy and paste buffers. This is something you get with GNU Emacs on an X system. I can use both kill/yank from Emacs while also using my normal copy and paste to maintain two independent copy and paste buffers, very handy
- Complete control over the editor, no longer do I have to deal with auto closing brackets or any other ‘helpful’ defaults the editor includes (You can turn them all off, but I get annoyed having to go change a bunch of settings)
- An unexplainable feeling of being closer to the system and the code.
Last Thursday, we had the opportunity to hear a talk from Jason Fried, CEO of 37signals. I had already read some of the 37signals philosophy in Getting Real (although it’s about time for a re-read), but the talk was still totally fascinating. Although in many ways they are similar to the Web 2.0 startups (they emphasize releasing early, focusing on the customer, and avoid detailed long-term planning), in other ways they are totally different (notably, they don’t work an insane number of hours a week).
Jason repeatedly said that their process was not the only way to successfully run a company – just the way that works really well for them. While I don’t think every piece of advice will be useful for every startup, I’m betting that everyone can learn at least a few very useful things from Jason. I know it got my mind spinning about ways we could improve how we work at Devver.
Without further ado, here are some nuggets of wisdom from Jason, split roughly into two categories: Running a Company and Building a Product.
Running a Company
Focus on things that don’t change
- first-mover advantage is overrated
- the leaders today sat back, watched, and did it better
- invest in the things that won’t change (example: in ten years, people will still like simple software, so focus on simplicity)
- don’t try to chase the next big thing
- 37signals just wants to build a great products that people love
- they don’t have a five year plan
- they know they want to be profitable, but they don’t have a plan to get X users by Y date
Use ‘less’ to your advantage
- use your constraints to focus your attention on the most important things you can possibly do instead of everything you can possibly do
- less money is an advantage (you have to be creative to get the word out, which is more effective)
- less time is an advantage (focus on important stuff)
- fewer people is a good thing (less coordination necessary)
- 37signals don’t work on Fridays
- now Monday-Thursday people work extra hard, they waste less time
- they don’t make them cram in more hours (around 8 hours a day, four days a week)
- the output has been better, they are more refreshed
- great for employee retention
- they pay for employees to pursue hobbies outside of work
- if they pay for hobbies, the person has to teach everyone else the stuff they are learning
- they don’t spend money on advertising
- the most famous chefs are famous because they teach others
- out-teach, out-share, out-contribute your competitors
- don’t be afraid of competition stealing your ideas
- if you teach, you have people’s mind even if you don’t have them as a customer
- amass an audience, then you can sell them something
- it’s the biggest enemy of productivity
- look to minimize interruption
- they don’t talk to each other
- at 37signals, everyone usually works from home
- there might be 4 months where they don’t see each other, but they collaborate passively via Campfire
- there is no such thing as a rock star developer, only rock star environments (those that make developers productive)
Don’t hold meetings
- no meetings at 37signals
- they are a huge waste of time
- they last too long
- information per minute is really small
- think about the total cost (10 people attending a one-hour meeting == 10 hours of lost productivity)
- if you make a mistake, come out immediately, admit it, move on
- don’t try to hide mistakes
- be part of the conversation about you screwing up (because the conversation is happening anyway)
- the more you admit you are wrong, the more people like you
Avoid these words: “Need”, “can’t” and “easy”
- these are the words that cause things to be late, to be difficult, to be contentious
- people use the word “easy'” to describe other people’s work (e.g. “That feature should be easy to implement, so let’s have it by tomorrow”)
- you don’t need most things you say you “need”
- “can’t” is also unnecessarily strong
Don’t scar on the first cut
- don’t institute a policy every time one little thing go wrong
- if problems arise, deal with problem on individual basis
- treat people with respect, not rules
- small companies should not try to be big companies (big companies are wishing they could be like small companies)
- if employees know you trust them, they won’t abuse that trust
- example: everyone at 37signals has a company credit card they can use for anything they want (not necessarily work related)
Don’t only hire on specific skills
- curiosity is the most important trait. Curious people want to learn new things and appreciate other people’s work
- if you want to know how curious someone is, just ask them the last (non-work related) thing they learned
- always hire good writers, that’s more important than specific skills
Pick your clients carefully [this was targeted at service companies]
- you can choose the work you do
- find the right kind of clients
- you don’t need every customer
- you can’t make everyone happy
- if you take on everything you can at first, you’ll never stop, and after 10 years all your projects will suck
Let customers pay right away
- don’t pester users to get them to upgrade
- most of their paying customers started w/ paid version (as opposed to using the free version for awhile and then upgrading)
- ask people for money right away if you want it from them
Don’t worry about the competition
- they will change
- you can’t control them
Building a Product
- it’s vastly overrated
- just build the thing
- don’t let planning scare you into not doing something
- spend 95% of the time on the real thing
- you always know more about the project after you’ve started working on it
- diagrams, wireframes, proposals aren’t real
- just work w/ the real thing
- fake things create an illusion of agreement (if you think you are all agreeing to the proposal, you aren’t. Everyone interprets it differently)
- get rid of documents, artifacts – anything that you file in the cabinet after you complete them
- don’t represent the thing you are building, just build it
Error on the side of simple
- every mistake they have made is because they tried to do too much
- do the simplest possible thing for any problem
- get it out, let people try it out, then iterate
- always do the easier/faster/simpler thing
Don’t focus on details early on
- it’s a waste of time
- the things that are done early will probably be redone anyway
- polish is important, just do it later
Solve atomic problems/make tiny decisions
- people try to solve problems that are too big
- break down big problems down to the atomic level
- you can easily solve small problems (and if you do it wrong, you can go fix it easily)
- if you solve a big problem incorrectly, you won’t go back to fix it, because you invested so much in it
- 37signals doesn’t work on anything more than a week
- they often just solve a quarter of a bug
- morale is killed by people working on big problems that never get solved
Give up on hard problems
- they aren’t worth solving
- let your competition solve hard problems
- there are so many easy problems that need really good solutions
- take a step back, figure out what the core problem is
- take a few days off, look at it again, there may be a simple problem instead
Say “No” much more than “Yes”
- say no to everything (to customers requests, to features you yourself want)
- you think you need to give everyone everything they want, but you don’t
- make a feature/request really fight to be in the product
- as a product designer, you are the curator, you are the editor, you have to say no
- once you start hiding stuff in your product, it’s too complicated (if users have to turn stuff off, that’s a bad sign)
- it’s really hard to take away features from people (even if they are bad)
Be careful when adding features
- they read every feature request, then throw them away
- they used to keep a huge list, but no one looked at it because it was too long
- now they just notice the stuff that gets asked over and over
- look out for the “bananas in the lasagna” (even if everyone asks for something, if it doesn’t fit w/ the product, don’t add it)
- think very deeply about requests, even simple features have a lot of implications
- customers talk in solutions, you need to look for problems and solve those
- improve things for the majority, not the vocal minority (vocal minority can destroy a product)
Eliminate product management
- if you have a product manager, the product is too big and complicated
- the builders should be able to manage the product
People are complaining that GoDaddy censored a security site, bid against customers in domain auctions (more), and totally screwed up .me registrations. There’s even an entire site dedicated to exposing GoDaddy’s problems.
We had been lucky enough to never really have any problems with them. Since everything worked for us (even though we hated their UI with a passion) we have stuck around. Moving 20+ domains to another registrar just seems like a hassle. We run most of our services on our own server so we didn’t think we had much of a problem.
One service we didn’t run was our own mail servers. We didn’t want to use GoDaddy’s webmail, but thought just having GoDaddy forward mail would work fine. We forwarded all mail to our Gmail accounts, and after that it was simple to send and receive from Gmail, essentially taking GoDaddy out of the picture. We had run GoDaddy email forwarding for a few sites for over a year with no problems.
In the last couple months we started having problems with our email. We were getting reports from friends having problems emailing us. People were receiving random bounced emails, some emails when retried never would reach us, others would arrive successfully the second try. We were concerned but the issue seemed to occur rarely and usually simply resending would solve the problem.
Then it seems the problem got worse. After sending out an email and not hearing back, we received emails explaining that every time anyone responded to our last email it would bounce back. The bounce message warned that the message was a spam or virus and it would not be delivered. Hmmm… not good. We looked into it and found that we couldn’t send the original email to each other, without getting bounced error responses either. The email include a video link to download our presentation from DropBox, which GoDaddy filtered as spam. We had the same issue receiving responses to emails with RightScale’s developers. After making sure I hadn’t accidentally turned on any spam protection for our forwarded email accounts I called GoDaddy support.
Convincing GoDaddy that emails were being marked as spam by their servers, as opposed to other email servers took awhile. Finally after talking to internal GoDaddy tech support they acknowledged it was their email system. They explained that all emails including forwarding accounts go through a GoDaddy-wide spam and virus scanner which won’t let anything flagged through. I explained I wanted to disable their filtering and trust Google to do my spam filtering for me after my mail is forwarded. This was not an option as the shared filter is in place for all GoDaddy email. I then asked about the criteria of flagging emails, which I know in our case contained no spam links or viruses. I was told that if a single virus or spam message was sent from a domain it would block all emails linking to that domain. This is clearly a bad policy.
Blocking all of DropBox is an example of why this shared filter is bound to block valid emails. DropBox allows any arbitrary files to be uploaded by users, of course some virus-infected file has ended up on their domain. After some virus-infected file hosted on DropBox was emailed to a GoDaddy user, it was added to the blocked domain list for GoDaddy’s email filter. As a result we can never mail a presentation video file hosted on DropBox.
That’s pretty amazing, but the best part is there is simply no way to opt out. There was no way to get domains removed from their blacklist. One of the scariest things about this is that they only filter incoming mail, so we can email out supposedly virus-filled emails, but then if anyone hits reply it will bounce because our link will be a part of the response message. This leaves the sender blind to the problem. Who knows how many people we have emailed in the last 3 months that tried and failed to ever respond to us.
After learning all of this, I did the only reasonable thing. I switched mail providers so our email wouldn’t touch GoDaddy at all. We are now hosting devver.net email accounts with Gmail for your domain. It was easy enough to set up, and we have already seen that we can send supposedly risky emails through our new email servers. I guess I should start listening to everyone’s horror stories about GoDaddy and the next time I purchase a domain, I can slowly start moving away from the terrible beast.
We had a very exhausting but incredibly useful day last Wednesday. After being invited to give a talk at Pivotal Labs, so we planned a quick trip to San Francisco and arranged other talks with various Ruby developers. We arrived in SF a couple hours before our first meeting, so we headed to a coffee shop to grab some breakfast. We booted up 15 servers so we could do a live demo of Devver. Then we headed out to meet up with Aman Gupta from Kickball Labs (no site yet). Aman contributes to various projects including EventMachine and Ramaze. We ended up discussing distributed Ruby messaging systems and Ruby web frameworks, which seemed to be a shared interest.
Next we headed over to Pivatol Labs to prepare to give our demo. Pivotal has an awesome setup so it was cool just to check out their office. I particularly liked the flat screen displaying the current status of all their projects and the Wii/Rockband setup. Pivotal recorded our entire session, so we will link to the video when they put that up on the web. I think this was the best session we have had yet talking with developers about Devver. The group asked a lot of questions, and really shared what the pain points are for their teams in terms of Ruby development. We are hoping to get a few things finished and then be able to find some more time to talk with the Pivotal Labs teams. Thanks again to Pivotal for inviting us out in the first place.
While at Pivotal, we got a chance to talk to some people from other Ruby shops around SF and a friend of a friend Todd Sampson from MyBlogLog. One person we got to talk with was James Lindenbaum from Heroku. Heroku is also working on some awesome things in Ruby, like the Rush Ruby shell. We are also a fan of Heroku because they are also a big proponent of Ruby testing, so it was cool to hear their thoughts on what we were up to.
We grabbed some lunch provided by Pivotal and started running over to Yahoo’s Brickhouse for our next talk. We met up with the FireEagle team, which is working on some cool location based stuff in Ruby. FireEagle is the largest Ruby team within Yahoo, so it was great to get to hear their opinions on Ruby development and their team’s process. We sat around talking about current Ruby tools, and what kinds of tools and code statistics they would like to see. Seeing more overall statistics on a project seemed like a minor but important theme of our SF trip.
The last part of our SF trip was a happy hour with the SF Ruby Meetup Group. Unfortunately, due to some poor planning on my part, it fell apart. Some Rubyist from the group recommended meeting at Thirsty Bear. The bar happened to have a private party that night. I arrived about 10 minutes before we were supposed to meet, with no real access to email. So I left information at Thirsty Bear about heading to the nearest bar, hoping some Ruby users would find me… only one person from the Ruby Meetup managed to find me, John Mount of Venue Software. So I guess I might have to try this again next time we visit.
Thanks to everyone we got to chat with, we had a great and fast visit. We learned so much we actually have had to take a step back and really think about the best direction to pursue. I think the information we learned during our brief trip will help shape some of our decisions for a time to come.
After being asked by just about everyone what our company’s Twitter account was, we finally created one. We now have our very own Devver Twitter account. You can follow us to see what we are up to, and comment about Devver on Twitter with the all-powerful @devver symbol. Hopefully we will have some interesting thoughts and updates to broadcast out to the world. If you are into Ruby or development tools, here is one more way to keep tabs on what we are up to.
Ever since starting our company Devver, I have found it hard to type the words developers and development. I often just end up typing “devvelopers” and “devvelopment” without even blinking an eye. It is just so nice and easy to throw our extra ‘V’ in those words, it rolls off the tongue, so to speak. I am thankful that I have spell check on nearly everything I write now, because I am sure I would be sending out a ton of typos in my emails. Just one of the many small things to change in my life since moving to Boulder, and getting started with Devver.