10/01: SOLID Study Group
Week 1: S(ingle Responsibility)
Week 2: O(pen/Closed)
Week 3: L(iskov Substitution)
Week 4: I(nterface Segregation)
Week 5: D(ependency Inversion)
Week 1: S(ingle Responsibility)
Week 2: O(pen/Closed)
Week 3: L(iskov Substitution)
Week 4: I(nterface Segregation)
Week 5: D(ependency Inversion)
Remember Office Hours in University? If you don’t, it was a time that professors just left open in their calendars and students could book some time during those blocks to come and have a chat. As a student, you usually went to the office hours for the classes you cared about most, or maybe the class where you were really struggling but wanted to do well. It was part brainstorm, part catch-up, part therapy. It was a chance to clear your head and perhaps it kept you out of the weeds for a few weeks after. Sometimes it was the only time you got to talk about a paper or a project that you’d worked on for weeks or months.
Building products, as an entrepreneur or a product manager, can sometimes feel a lot like being a perpetual student. You are always faced with new information coming at you, you have to synthesize it, make decisions and make the idea your own. A lot of the time you’re going at it alone or with a very small team, and you often feel pretty isolated. What do you do when challenges come up, like when sign-ups drop, or your growth levels out? Who do you talk to?
Pivots have met a ton of CEOs and Product Managers at meet-ups and conferences who are working on great ideas and have really promising products. We shoot the breeze, take a look at their products, offer ideas, and help them focus on the possible solutions. The appreciation we receive often seems disproportionate to what we think we offer until it came clear how valuable collaboration and community is when you feel as though you’re doing it alone. So we formalized the process and rolled out Pivotal Labs Product Office Hours. This program of lunches, where Pivotal Product Managers and Designers meet with people who are building things and chat about the challenges they face, went live in NYC and San Francisco last year. We are really psyched that we are now bringing it to our London office in Autumn 2014.
So what’s the deal, really (I hear you ask)? The deal is that you send us an email to firstname.lastname@example.org, tell us a bit about yourself and your product (Make sure you mention you’re in London.) Someone will be in touch to schedule our lunch and maybe ask some clarification questions. Then you come down to our Old Street office on a Friday from 1230-130pm, eat some free lunch and a few Pivotal Product Managers and Designers offer you no-holds-barred advice on how to tackle your most pressing product issues. Can you come in again in a few weeks to let us know how things are going? YES, please do. The lunch is free, the advice is free, the bus fare over costs £1.45. There’s really no reason not to sign-up and come in.
So what’s in it for Pivotal Labs? Well, we get to meet awesome people who are doing cool things. We get to exercise our critique muscles and we get to have cool conversations. If you want some more specifics, you can check out these blogs about WeeSpring and Notable and how to frame your problem, to get an idea of how these sessions go. There is no general template, each session evolves in response to the product discussion at hand.
In this blog post we describe a process to replace a VMware vCenter Server Appliance’s (VCSA’s) self-signed certificate with Certificate Authority-signed (CA-signed) certificate.
VMware has already described such a process in Knowledge Base Article 2057223; however, the process they describe is cumbersome: it requires SSL certificates for four services that the VCSA provides.
We are not interested in replacing the SSL certs for all four services—we are only interested in the replacing the certificate that our web browser encounters we browse to the vCenter (i.e. the vCenter Server / vCenter Single Sign-On (SSO) certificate).
Also, we do not have four CA-signed certificates to install; we have but one wildcard certificate (*.cf.nono.com) available.
Following this procedure will result in an unsupported configuration! Wildcard certificates are not supported according to the Knowledge Base article:
“The use of wildcard certificates are not supported with vCenter Server and its related services. Each service must have its own unique certificate”
We feel comfortable in replacing one of the certs with a wildcard certificate in spite of VMware’s prohibition, for we are still maintaining four different certificates for the different services (though one of the services will be using a wildcard certificate).
In Cloud Foundry Engineering the Chrome Web Browser is the most popular browser among the developers, but it is not without shortcomings, especially with regard to self-signed certs.
Google’s Chrome web browser under OS X has difficulty permanently storing exceptions for websites which have self-signed certificates (a complicated work-around would be to visit the site in Safari and store the exception in the System’s keychain). Every time Chrome is restarted and the site with the self-signed cert is visited, the user encounters a warning screen. To make matters worse, a recent Chrome update requires the user to click not once but twice to get past the warning screen.
A fix would be to use CA-issued certificates for frequently visited internal servers. It’s trivial to install certificates on most servers, but the vCenter Server Appliance is a more complex install.
In this example we replace our vcenter server’s (vcenter.cf.nono.com) self-signed certificates with CA-signed certificates:
# set our shell variables (substitute as appropriate) VCENTER_FQDN=vcenter.cf.nono.com SSL_KEY=*.cf.nono.com.key SSL_PEM=*.cf.nono.com.pem # copy the key, .pem, and certificate to the vCenter scp $SSL_KEY $SSL_PEM $SSL_CRT root@$VCENTER_FQDN: # log into the vCenter ssh root@$VCENTER_FQDN # set our shell variables again SSL_KEY=*.cf.nono.com.key SSL_PEM=*.cf.nono.com.pem
# stop SSO and the vCenter Server service vmware-stsd stop service vmware-vpxd stop # install the .pem and key /usr/sbin/vpxd_servicecfg certificate change ~/$SSL_PEM ~/$SSL_KEY # wait for "VC_CFG_RESULT = 0" # start up SSO vCenter service vmware-stsd start service vmware-vpxd start
shutdown -r now
Make sure the key, .pem, and certificate files end in a newline (‘\n’, 0x0a, Ctrl-J). When using Github’s gists, for example, it is easy to accidentally omit a newline at the end of the gist.
Every Wednesday, Pivotal Labs Product Managers gather over lunch. Sometimes we discuss a book we have been reading. Other times we discuss a particular client’s product and offer feedback. Recently we have been trying a bit of an experiment: we critique products on Product Hunt. Informally, we have started to refer to these exercises as “product hunts.” For 60 minutes, we dissect the product, business model, and technology, and throw our thoughts on a mural to post here.
This week’s product hunt was special because we selected from this years TechCrunch Disrupt finalists, ultimately critiquing the winner of the competition, Alfred. Alfred is the “first human powered operating system for your life.”
Check out the discussion via the mural.
We shared 40 hours a week, a screen, a product, client relations and a problem space. Now we’re on a quest to codify the tenets of pair design.
We designers are an interesting bunch. Snowflakes. Unicorns. Butterflies. Rock Stars. Special. We. Are. Special. Our habits are also special and good and make us individuals which in turn makes us creative, critical and exploratory. In all of this, we can develop little quirks of personality that surface when design pairing.
Rather than fix, just accept. We all have our own odd extra ears and whatnot. Embrace it. Grow your own practice by fully understanding the motivations that drive your design buddy to do all the crazy things that make you want to nibble on glass.
Remember, our greatest strengths are often our greatest weaknesses. So be kind and patient with your design pairs. If you are working with someone, it is because they are talented. Their habits are actions that spur from what they value. If you can figure out what they value, and you can learn about their practice, and in turn grow your own practice. Nobody said it was easy, dangit.
More in the pair design series:
With their high revenues and established market presence, the top 10 U.K. mCommerce retailers (based on Internet Retailer’s Top 500 Mobile Guide) certainly have the resources to build stellar apps that drive revenue, brand awareness, and customer loyalty. So why are some still falling behind, launching poorly executed products that tarnish the brand image and turn customers to competitors?
We investigate these issues and more in the report. Our 2014 report delves into the features that are critical to success and assesses whether U.K. retailers are meeting the needs of their mobile users. More areas of coverage include:
Download our exclusive 2014 U.K. Retail Apps Report to understand what retail apps are leading, what makes them successful, and why mobile is an opportunity for all retailers to boost engagement and drive the bottom line.
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: email@example.com
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 : firstname.lastname@example.org
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: