Host: Mike Dalessio
Host: Mike Dalessio
Host: Mike Dalessio
Host: Vanessa Sant’Anna
Host: Josh Knowles
Host: Tim Coventry-Cox
Deep Web, Open Source Intelligence, and The Bad Guy
Host: Ward Penney
Here at Pivotal, we know pair programming is great. We strive to pair 100% of the time.
Sometimes, a pair might want to work on something complicated by getting in the zone together – to listen to music while pair programming. (It’s best when your pair shares the same taste in music as you!)
Other times, a pair may need to answer a call from a remote pivot or client. They typically will want to do these things while also avoiding disturbance to the team and the rest of the people on the floor.
Still other times, one pair might have trouble hearing with the background noise on the floor, and want to use headphones to amplify their pair’s voice above the noise.
If you’re an aircraft pilot – or you’ve been in an aircraft with someone who is – you’ll have seen how well a plane’s headset system works:
– The pilot and co-pilot have microphones that send audio to each other’s headphones, so they can talk to each other at any time.
– There is a “transmit” button, which causes what both people say to be transmitted by the plane’s communications system on whatever channel is active.
– The pilot and co-pilot both hear the plane’s communications system through their headsets.
This walkthrough will set up something similar in software, which will let you and your pair wear USB headphones, adjust your volume individually, and both “transmit” to people you work remotely with. This setup is something you won’t know you need until you try it!
Following these steps will route the audio from one microphone to the other headset, and vice versa.
1. Plug in both pairs of headphones. We use Logitech G35 USB headphones for their great sound quality and convenient microphone mute button.
2. Download LineIn from Rogue Amoeba’s freebies page.
3. Extract LineIn and option-drag it to create a second copy. The copy will be called “LineIn 2″.
4. Open both copies of LineIn. Arrange them so they’re not on top of one another. Configure one LineIn to send audio from one left pair of headphones to the other, and configure the other LineIn to send audio the opposite direction.
5. Click “Pass Thru” on both instances of LineIn to start your headphone pairing setup.
6. You should now hear each other while wearing your headphones, which cancels out some of the noise on the floor.
This lets you block out background noise and deal with any hearing problems.
1. Open “Audio MIDI Setup” (via Spotlight with Command-Space).
2. Click the “+” icon at the bottom left and select “Create multi-output device”.
3. Select your new multi-output device on the left hand side.
4. On the right hand side, ensure only your two pairs of headphones have checkmarks next to them.
5. Right-click the multi-output device and choose “Use this device for sound output”.
6. Optionally, right-click the multi-output device again and choose “Play alerts and sound effects through this device”.
7. Open iTunes or your music playing program and make sure it is configured to output audio to the default system device.
8. Adjust the volume so it doesn’t drown you out, and enjoy your music.
9. If you find your pair is quieter or louder than you and want to change the mic volume, select the headphones you want to adjust. The “M” slider on the “Input” tab controls your microphone volume.
10. You’ll also notice the multi-output device does not let you adjust the volume the normal Mac way. If you want like your volume louder than your pair, adjust the “1” and “2” sliders on the “Output” tab for your headphones.
Great, now you and your pair can zone out.
At Pivotal Labs we like to help clients and developers in other offices by joining remote calls. Pivots may use Screenhero to remote pair with them, or may join a Hangout or Skype call. The cross-headphone music setup forms a foundation for remote calling between pairs. In stage 3, you will combine both microphones.
(Side note: you may have read about an “aggregate device”. We don’t use the aggregate device because the two microphones become 2 separate input channels. Applications that use microphones assume a single input channel. So your remote person will only hear one microphone.)
1. Download and install Soundflower – we won’t be using its user interface, so you can Quit the icon in the menu bar.
2. Open “Audio MIDI Settings” again, right click “Soundflower (2CH)” and select “Use this device for sound input”.
3. Where you made 2 copies of LineIn in stage 1, option-drag again to make “LineIn 3″ and “LineIn 4″.
4. Open your third and fourth instance of LineIn and arrange the windows so they are not on top of one another. Use both instances of LineIn to send audio from each pair of headphones to “Soundflower (2CH)”. Click “Pass Thru” on both to start them sending audio.
5. Ensure your application – eg. Screenhero or Google Hangouts – is configured to use the default system device for both input and output. Note that Chrome doesn’t allow microphone access in Incognito mode.
6. You’re done – go make your remote call.
These instructions should only take a few minutes – it is worthwhile to invest time in an ideal setup because you typically work with remote people for an hour or more.
But be careful: developers wearing headphones can be detrimental in the long run so consult your anchor and PM to decide whether this suits your team and project.
If you need help ask in the comments. Enjoy your new headphone pairing setup!
PWS is Pivotal’s public Platform-as-a-Service offering. PaaS systems let you host apps by pushing them to a service rather than having to configure and maintain separate installations of web servers, load balancers and so on. PWS is a hosted installation of the open-source Cloud Foundry project, to which Pivotal is a primary contributor.
You may be familiar with Heroku, one of the first cloud application platforms. PWS (or ‘p-dubz’, as it’s affectionately known at Pivotal) occupies the same space as Heroku, and as such is a competitor.
Although earlier in its development than Heroku, PWS is a very stable, viable alternative. It has several advantages over Heroku, but also has a few disadvantages, which the team are working hard to eradicate in the near future.
Because it’s a Cloud Foundry installation, the PWS command line interface isn’t coupled to a version control system, as Heroku’s is to Git. I could, for example, start a quick project without version control and have it publicly available on the web using PWS in a few minutes.
This is a big advantage for teams using other version control systems. It’s also great for trying things out without committing them to version control. I shouldn’t have to change history in order to tidy up some commits that were only created to test the waters of my cloud platform.
If your organization is considering installing a private Cloud Foundry installation, such as Pivotal CF, then you can apply your knowledge of interacting with PWS to that system too. It’s simply a case of targeting a different API:
cf api https://my.internal.cloud/
…and then pushing your app again:
PWS charges by memory used by apps over time, and per month for any services used in the marketplace. You can try the system out for free for 60 days, after which apps are pay-as-you-go.
One advantage PWS has over Heroku in this area is that you can determine exactly how much memory to allocate, and therefore pay, for a given app. Whereas Heroku requires its users to allocate chunks of 512MB, on PWS I could choose to allocate 5309 megabytes to my app if I so wished.
We have a dedicated Cloud Ops team who maintain the system, so you don’t have to be up in the middle of the night when a server gets upset. In addition, we have a highly knowledgeable support team, known to get customers out of pickles entirely unrelated to PWS. There’s also an active forum.
Cloud Foundry has a plethora of docs ranging from guides to reducing downtime with blue-green deployments to sequence diagrams of the internals. We have a large and growing dedicated documentation team that is constantly reviewing and improving our written material.
One-off tasks such as database migrations on PWS aren’t quite as slick as you may be used to on services like Heroku. Whereas on Heroku you can:
heroku run rake db:migrate
On PWS the traditional workaround for a lack of support for one-off tasks is to run migrations on one instance as part of the app’s startup command. Details of this and other techniques are on the Cloud Foundry database migrations documentation.
Heroku boasts many more add-ons than PWS. If you can’t wait for more vendors to join, however, you can easily create your own service that bridges the gap between any SaaS provider and PWS.
If you’re on the lookout for an easier, cheaper, or more compatible way to deploy and maintain your apps, signing up for PWS is painless. It’s also a skill worth acquiring: as more companies adopt Cloud Foundry as their platform of choice, your experience with PWS will stand you in good stead for pushing apps to those internal platforms.
If you have any questions about the service, feel free to add a comment to this post.
What was the worst thing that a startup could do when working with her?
Fran thought about it for a second, and replied:
She went on to talk about how if someone is supposed to send her something after they meet, that forgetting to is not going to help build the relationship. Fran added that sometimes people spend so much time making sure the deliverable is perfect and end up missing their opportunity to stay front of mind.
A great follow-up can set you apart, especially if it’s timely.
I remember, when I was a Cornerstone on Demand, that one of our PM candidates found a way to have hand written thank you notes delivered to each person who had interviewed her… THE VERY NEXT MORNING! We hired her for a variety of reasons, but that was something each of us remembered for years.
Follow-ups are a great way to continue a conversation and stay relevant.
Camp Interactive, which visited Pivotal Labs a month or so ago before they spent a week building apps, sent me the most adorable thank you note today.
Here’s what I love about it:
Things like this make me want to help Camp Interactive out in the future, and may have encouraged one of my coworkers to run a marathon for them. Now that’s an impactful follow-up.
You may know Pivotal for their great enterprise offerings and the Pivotal tracker. Did you know they have an amazing product team as well? After connecting with PivotalLabs, Serge and I attended an “Office Hours” session a few weeks ago to learn more.
Pivotal’s Office Hours for Product is new. Every week they invite startups for a free lunch with a side of product grilling (a community service!). They get in touch beforehand to get a sense of how they can help, then spend Friday lunch brainstorming. In our case we knew (then and now) that our first “user experience” of Knotable needed a thorough shake-up.
We met Tami, Jeana and Lauren in the lobby of Pivotal’s awesome Chelsea offices. Then got straight to the main event; lunch. I picked a scrumptious mediterranean blue cheese salad. Serge had a Californian affair.
We went to a meeting room and got down to the (actual) main event. Lauren did the honors of going through a “first user experience” of Knotable, monologuing her impressions (in impressive detail) as she went. Tami and Jeana took notes and added commentary. Serge and I scrawled furiously and tried to keep as quiet as possible to avoid bias.
Once Lauren was done, we put our heads together. Tami took charge by organizing everyone’s comments into a collage of sticky notes on the whiteboard. We broke them up into roughly five categories: On-boarding Issues, Usability, Inconsistent Design, Unclear Messaging, and Expected Behavior.
That’s when things got real. We all chipped in like front row kids in school, trying to get our observations and insights on the board. There were no holds barred by the Pivotal team. Their comments were incisive and on point. Some of their feedback was familiar, but much of it was novel and illuminating. Having three fresh sets of trained eyes on our product was productive.
No sooner had we started, then it was all over. We packed up the stickies from the board, cleaned up our plates and said our farewells. Tami mentioned that teams often found it useful to return after about a month to review their progress and invited us to do the same.
We both found the experience helpful. Anyone looking to get an honest bit of constructive criticism from some of the best product people around should get in touch with Tami to set up your own free lunch.
To have your startup participate in Pivotal’s Product Office hours, apply here.
Based in Dallas, Savoya is currently building out their tech team from the ground up with the help of Pivotal Labs.
This is a great opportunity to join a thriving company. If you’re interested in the position please reach out to the savoya team here: firstname.lastname@example.org
ESSENTIAL DUTIES AND RESPONSIBILITIES:
We are looking for a team of two developers located in Dallas, TX to work in conjunction with Pivotal Labs to create our next generation internal and external software platform. Become founders on our new development team – set the culture and build something excellent from the ground up. Create an exceptional, custom-built global chauffeur logistics management solution for the most discerning global travelers. Responsibilities include interpreting requirements to identify and evaluate solution alternatives, developing and deploying high-quality applications. You will be part of a team that prides itself on its ability to continuously release reliable, scalable, high-performance technology solutions using modern design and development patterns. You will be an integral part of a strong, tightly-knit, collaborative development team working with a product owner and other key internal stakeholders.
Proven experience in development of flexible and scalable web-based applications
Passion for technology, specifically software development
1+ years of experience with Ruby language and the Rails framework, be proficient with the entire Ruby on Rails stack
3+ years of hands-on web development, demonstrating:
Sound object oriented design skills and knowledge of application architecture patterns
Proficiency with relational databases, including design and development
Working knowledge in development of MVC-based web solutions
Ability and desire to thrive in an Extreme Programming environment, including pair programming
Competency managing source control and automated build processes
Excellent analytical and problem solving skills
Strong communication and interpersonal skills – eager to dialogue directly with process owners and system users
Our team delivers perfectly executed ground transportation in 60 countries worldwide. Our clients are meeting planners, flight schedulers, executive assistants and travel planners who expect the highest levels of responsiveness and reliability. Since 2000, we’ve been redefining customer service and delighting clients with a stress-free ground transportation experience. When it has to go right, trust Savoya.
Experience with agile software development methodologies such as SCRUM and/or XP
Working knowledge of test-driven development and related frameworks (i.e. Jasmine, RSpec)
Working knowledge of associated deployment platforms and technologies (i.e. Heroku, AWS)
Mobile app development and Salesforce familiarity is a plus
Contact : email@example.com
Don't just throw runtime exceptions when disabling NSObject's
init because you're using a designated initializer instead. Be friendly to your fellow software developers and mark the original
init method as unavailable with the following compiler attribute:
What’s the hardest thing about becoming a new mom? According to Ally Downey, it was knowing what to buy. “The first time I walked into a Babies R Us, I burst into tears,” she said. “I looked up at a ten-foot wall of baby bottles and saw — in all of those options — a metaphor for how completely unprepared I was for the hundreds (thousands!) of choices I’d have to make for my baby.”
She turned to her friends for help and found they were eager to share what to buy and what to skip. “…[A]s my inbox flooded with advice from my in-the-trenches friends, I started to feel a little less overwhelmed and a little bit more ready. By the time my baby arrived, I’d become one of the ones sending the instructive emails (Get Triple Paste in the tub, not the tube!).”
She saw not only a tremendous pain point for parents, but a huge business opportunity, with new parents spending roughly $5,000 on baby products in year one alone. So soon after her first child was born, Ally launched weeSpring — a place for expecting parents to find reliable advice on what to buy, and for new parents to share what they had learned. A year and a half later, weeSpring is a vibrant community of new and expecting parents with over 150,000 product ratings. Expecting parents can log in via Facebook to see what their friends have reviewed, save products for later, and build lists like “Newborn Necessities,” “Teething Time, and “Best Gifts for a One-Year Old.” New parents can share their own tried-and-true advice and learn about new products as their baby grows.
Like any growing startup, weeSpring has been experimenting with ways to reach new users. By writing a blog that details their favorite products and tips, building a strong Pinterest presence, and experimenting with paid advertising, they are seeking out the most effective channel to reach new and expecting parents that convert to registered users. As they sat down to analyze which experiments were converting the best, however, Ally and her co-founder Jack found a pattern they didn’t expect.
weeSpring had stumbled into a classic startup challenge: new users coming in through the “back door” (from search or referral) did not understand what weeSpring was and how it offered value. They were not signing up and they were not reviewing products. In short, they weren’t behaving the same as new users who came in through the “front door” (from weeSpring’s homepage, which has a strong onboarding flow).
weeSpring signed up for Product Office Hours to get some advice on what to do next. Product Office Hours is an hour of free consulting offered by Pivotal Labs for startups who want advice on how to move forward when confronting a particular challenge or feature.
We (the team at Pivotal Labs) helped weeSpring identify that they were ready to dedicate design and development resources to address the needs of their new back door users. We then led them through two activities to design an experiment to focus on converting back door users.
First, we determined the goals of a back door new user who had clicked onto a weeSpring product page (e.g. Aden and Anais swaddle blankets) from a blog post, a Pin, or a newsletter, but had not yet signed up. We concluded that back door users wanted to:
Second, we needed to figure out what had to be on the page so that a back door user could achieve his or her goals. We determined this in four steps:
Ally and Jack walked out of Product Office Hours intending to roll out an experiment with the goal of improving conversion on logged out product pages for first-time mobile users.
Several weeks later, they rolled out small changes to their logged out mobile page. Since the change, they are seeing two positive signals:
You can see the changes that the team made in the screenshot below, which compares a logged in (L) versus logged out (R) product page on mobile.
By making small, pointed design changes to focus on purchase, conversion, and communicating their value proposition, weeSpring has been able capture more new users to sign up and buy. They can now feel confident making bigger changes to product page because they have validated the basic concepts.
We’re looking forward to seeing their new product page, as well as new experiments to encourage back door users to complete front door activities (such as rate and review products).
Need Product Advice? Pivotal Labs now offers Product Office Hours. Learn more or sign up here.