Skip to main content

10 Reasons I’m Going to Cloudstock on Dec. 6th


Cloudstock, an all day event for developers focused on developing in the cloud, will welcome a large number of thought leaders and business leaders in the cloud as sponsors and presenters! Cloudstock is on the day before salesforce.com’s annual user conference, Dreamforce.
As a sponsor of Dreamforce, we’re busy gearing up by creating new samples, developing a new integration with a key partner and creating new presentations to show how developers can use electronic signatures in the Cloud. While the pressure will escalate up to the very last minute, we’re setting aside the last day before Dreamforce for Cloudstock.
The top 10 reasons the DocuSign technical evangelists are taking a full day for Cloudstock:
  1. John Musser’s evaluation of the Cloud API landscape: John and the entire ProgrammableWeb team keep their hands on the pulse on most of the web services – we’re looking forward to a big picture view.
  2. Session from Box.net’s Hieu Nguyen and Jeremy Glassenberg: Sometimes we get so caught up in the web services that it’s good when an expert like Jeremy steps out and shares a holistic approach to integration. You will definitely see me at the “Connecting Services Inside & Out: Thinking Outside the API” session.
  3. Dave Carroll’s deep dive into using the Force.com database: Accessing Force.com database through the web services has been on my “to-learn” list for some time. Who better to get an overview of Force.com technology from, than Dave?
  4. Learning about the interests of the PHP community: Many PHP programmers have joined the DocuSign developer program and it looks like Amazon has invested into showing how PHP can be used on their Amazon Web Services platform. I’d like to see what kind of questions interest the PHP community.
  5. Insights from Google: Google will discuss the Google Marketplace and since we just launched an e-Signature Marketplace, I’d love to hear what guys at Google pitch to their potential and existing software developers.
  6. Amazing demos: I’ve heard about Twilio’s amazing presentations, and though I personally have not touched phone technologies in ten years I am curious to see John Sheehan create solutions on stage right in front of the audience.
  7. Hackathons: I love hackathons; and while I am not the fastest coder, I enjoy seeing what other people can come up with in a short time. I also like to think that it’s just great to be in the running.
  8. Java + Force.com: I always loved Java. I enjoyed being part of the Java Community Process 10 years ago and defining some of the interfaces. The ability to use Java with Force.com is an amazing combination of winning technologies. VMForce.com is a promising solution for our customers and partners; I need to see what it’s all about.
  9. Networking! I am a natural networker – I like meeting new people especially if they are sharp and have good ideas! My first job ever was handing out flyers for my dad’s vet clinic at a dog show – ever since, going to expos and meeting people in the industry always puts a smile on my face. Cloudstock will be great for that.
  10. Someone mentioned there will be food… I just want to let everyone know that it still works, even years after college.
See you all at Cloudstock! Look for the DocuSign DevCenter team – Mike Borozdin, Julia Ferraioli, Craig Smith and Veronica Lentfer.

Comments

Popular posts from this blog

Quality of Code is Quality of Life

About 20 years ago when I started working in technology companies I remember “the best” engineers had similar patterns:
-They worked crazy hours
-They knew the systems no one else knew
-They could react and deliver something faster than anyone else
You could always hear other employees say: “Bob is really smart, no one knows how to get anything done in system X besides him!”

This reinforced optimization around being the only person who knew how to do something in some part of the code.  That in turn reinforced job security and bargaining for those engineers, but also chained them to a particular system.  We had big code bases of C++ or Java code where some “Bob” hacked up features as soon as he possibly could.  “Bob” would have occasional nuclear disasters where he’d sleep in the office or through the weekend and then everyone would thank him for how he “saved the day.”  “Bob” sacrificed his quality of life to get praise when he hacked stuff up quickly and then the second time when n…

SDET / QA Engineer Interview Checklist

After interviewing and hiring hundreds of engineers over the past 12+  years I have come up with a few checklists.  I wanted to share one of those with you so you could conduct comprehensive interviews of QA Engineers for your team.

I use this checklist when I review incoming resumes and during the interview.  It keeps me from missing areas that ensure a good team and technology fit.  I hope you make good use of them.  If you think there are good questions or topics that I have missed - get in touch with me!


SDE/T or QA Engineer interview checklist from Mike Borozdin
If you like this checklist you might want to check out these posts:
Emotional Intelligence in Software Teams  and Good-bye manual tester, hello crowdsourcing!

Code versus Configuration

At Ethos we are building a distributed mortgage origination system and in mortgage there is a lot of
different user types with processes that vary depending on geography.  One of our ongoing discussions is about how much of the logic resides in code vs. being in a workflow system or configuration.  After researching this topic for a bit, I have arrived at a conclusion that the logic should live outside of code very infrequently, which might come as a surprise to a lot of enterprise software engineers.

Costs of configuration files and workflow engines First thing that I assume is true is that having any logic outside of the code has costs associated with it.  Debugging highly configurable system involves not only getting the appropriate branch from source control, you also need to make sure that the right configuration values or the database.  In most cases this is harder for programmers to deal with.  In many FinTech companies where the production data is not made readily accessible…