Iterating on a new project: dayspace.co.

Dayspace is a shared economy play that allows people to rent out their empty homes as office space during the day. Also using this project to work on my responsive html/css skills. Just put the site up, so will be adding more forms and features soon as long as the feedback from potential customers is positive.

Recently I’ve discovered a few startups have been hiring for a role titled “Developer Evangelist”. Being curious, I decided to learn what this role entailed.

B2D (Business to Developer) startups have been trending lately due to increased API developments and a need for products built for developers. The Developer Evangelist role melds Engineering and Marketing to help promote a technical product to developers. This means improving the awareness of APIs through documentation, developer support, and community outreach at startup events.

 I recently had a chat with Vidyard and regarding what a Developer Evangelist does for these two companies.

Carter Rabasa is a Developer Evangelist Manager at Twilio. He mentioned their Evangelist role consists of 1) Event participation 2) Community engagement and 3) Writing technical content related to the different uses for their API. In a nutshell, inspiring devs to build interesting things, and reaching out to them via the web or at community events. Becoming a genuine member of the community is important he mentioned, because you don’t want to come off as a leechy salesman type. This is one reason why Twilio helps sponsors many startup events. As you could imagine, this role requires travel (up to 40%) to help engage developers in different cities.

Vidyard, a video marketing and analytics company, mentioned one of the most important characteristics of this role is patience. It would require customer support skills and an ability to relate to the customer. For Vidyard, their Evangelist role focused on API documentation and support.

General requirements for a Developer Evangelist

Developer Background – To be able to communicate with devs regarding APIs and usage. An understanding of multiple languages is important to communicate with all sorts of devs.

Interpersonal Skills – Developer Evangelists must be comfortable socializing with devs and joining communities!

Patience – Ability to clearly explain and be patient when dealing with questions or concerns.

Last Friday, we had the chance to see some of the final projects from the Bitmaker Summer Cohort. After only two weeks, the result has been some amazing MVPs. From dining deals and reservations to a Github for DJs, it’s amazing what we can build now.

Our Bitmaker project is up online at StayTraders.com. Create an account, play with it, and email me at sing.drew at gmail.com if you have any questions!

If you want to hear about the technologies we used and features of the site, feel free to read onwards.

StayTraders is an accommodation for skills exchange that allows guests to teach or work for their hosts. In return, they get a free place to stay. Users  can contact hosts listed on the site. If a host has accommodation available, they can then offer it to that person for a maximum of 20 hours of work a week. I’ve always enjoyed traveling and immersing myself in different cultures, which is one reason why seeing the physical MVP online has been so rewarding.

I was lucky enough to work with Eric Szeto. I feel we got along really well, and got into a solid work flow once we understood the goals of our MVP (I highly recommend interviewing him for his full-stack skills, and on top of that, he’s a personable guy who’s quite funny!). We managed our tasks with Asana, and scribbled text on a shared google doc when further notes were required.

StayTraders utilizes Haml, Sass, Sorcery for user authentication, pry for debugging, and bootstrap-sass. Instead of using CoffeeScript, we used javascript to try and cement our js understanding.

A cool gem we found was Figaro, which is used to keep our sensitive keys confidential since this is a public repo. And our site is hosted on Heroku’s handy setup!

For testing, we’re utilizing Rspec and Capybara. Our intention was to use BDD. Most of our views are covered, but admittedly we have fallen behind on the specs and need to spend some time catching up on them.

Carrierwave, mini_magick, and S3 – Our images are hosted on Amazon S3. We’re using the carrierwave gem for image uploads and a Jquery cropping plugin called Jcrop for image cropping. Configuring everything was a bit tricky because for some reason mini-magick wasn’t saving the cropped image coordinates (x, y, w, h). In our crop method, we then open the image and manually write the new cropped image dimensions to make sure it saves and displays properly (see asset_uploader.rb under app/uploaders)

State_machine -To get an understanding of state machines, we used them in our admin panel. We transition the state of a hosting to pending once it has been submitted by a user.
This allows an admin to approve the hosting for display on the site if all the requirements have been filled out.

Polymorphic assets – StayTraders allows multiple image uploads for both Profiles and Hostings. Initially, we set up lis_images and pro_images models and controllers, which wasn’t very DRY and became a bit confusing. We then refactored all our images into an assets polymorphic tree, which can be accessed by both Profiles and Hostings. Our assets table also has a column called “state” (probably not the best name), which is used to label whether an image is the default profile image or not (active or inactive).

Google Charts! – For logged in users, we recently implemented a google chart to display the country location of all hostings and people with a toggle button. Check out our maps_controller.rb for how the data is organized.

Mailers – Test our mailers :-). Upon registration, we’ve set up mailers to send an automatic email to the user. We’ve also implemented a contact form for both hostings and profiles, which automatically is sent to the recipient via email. It allows us to keep emails private until a user has reached out to another StayTrader.

Overall, it’s been extremely rewarding to work on this fun idea. Eric has been an awesome partner. His attention to detail is amazing, and I hope to be able to continue working on StayTraders with him in our free time.

Sorry for not posting since week three. It has been a mental marathon. My tweets, blog posts, and life in general have been cut down to maximize my learning over the last 10 weeks (ten because the Bitmaker week off provided an great chance to catch up and prepare for Rails).

Every day I’ve woken up and been excited for lecture to see what new skills we would gain. Some days have been a tougher grind than others. I’d equate the feeling of these days to being lost in the woods without a flashlight. Ramen dinners and late night sessions have become routine, but it has been an adventure. I’ve never ran a marathon or climbed a tall mountain, but I have to think there are some similarities in the mental mindset that is required during these activities of mental endurance. On days where you grasp concepts and make good procress, it feels like you’ve leveled up in an RPG or something. Ahhh, the new found hit points and tools you now have!

I’m excited to continue working on my skills. Whether or not I get a position during interview week, I’m stoked to see where I’m at in one month and three months. Analogy wise, I feel I’ve finally learned how to fish when it comes to programming, and the web has all the resources I need to extract the skills applicable to become a dev.

Next post: A summary of our Bitmaker Final Project!

And so it begins. Anxious and excited describe my feelings as I struggled to fall asleep the night before the summer Bitmaker Labs Cohort started on June 3rd, 2013.

Beginning a dedicated 9 weeks with aspiring developers is motivating. The eve of our first day, I met with four fellow students, which was great to discuss everything stirring in our minds.

On the 1st day we learned how to use unix, git, github, and how to utilize these tools to collaborate with others. For our group assignment. One person would clone the assigned Bitmaker repository and the rest would clone that user’s repo, updates to the file, then commit and push. It was important at the end for each team member to clone the repo to their own individual github account, which required the use of git clone.

Utlizing git remote -v was important to make sure, when pushing our new repo up, that we were properly pushing to our desired repo. https://help.github.com/articles/changing-a-remote-s-url

During certain periods of the day, I felt I had a strong grasp of the material, but at the same time, there were times were I felt lost and unprepared for the course.