- Date.today is not aware of the local timezone, but Date.yesterday is. Use Date.current or Time.zone.now instead.
- Hackathon May 12-13 for mobile game development. More info
“How do I not use VCR with Webmock in a spec?”
Use VCR.eject_cassette, see: docs
“Facebook now expires all tokens after 60 days. If you schedule a task with Facebook in the future it may use the expired token. Any solutions?”
Sadly there is nothing you can do. Send the user an email to re-auth.
“Good way to get replies on Twitter?”
Nope. Crawl thorough all your mentions, to get to your replies.
Good documentation goes a long way towards, not only helping others understand your code, but also simplifying re-use. Unfortunately, it seems that the moment documentation is written, it’s out-of-date from the code, especially if maintained separately in its own document.
When Sun Microsystems introduced Java, they also introduced Javadoc, which let their engineers, and other Java developers, document APIs “in-line”, next to the method definitions. Javadoc uses a simple markup language, embedding the documentation for a method within a
/** … */ comment block. Typically a Javadoc block starts with a sentence or two describing the purpose of the method or function. The purpose of parameters passed into the method are marked by
@param followed by the parameter name and its description. Finally the comment block ends with a description of the return value, preceded by
@return. This documentation lives in the class interface definition, making it easy to maintain at the same time as the code, ensuring that it remains up to date. The Javadoc tool can easily parse the source files, producing human-friendly, HTML documentation of the library classes.
Gentle Bytes’ excellent appledoc tool brings this easy documentation approach to Objective-C development. Simply comment the methods in your class definitions (.h) and run the appledoc application to compile beautiful documentation that both matches the format of Apple’s framework documentation and integrates directly into Xcode. Claus Broch provides a great blog outlining how to integrate the execution of appledoc directly into Xcode, further simplifying your documentation efforts.
Appledoc provides a simple and lightweight way to document your Objective-C code, making it easier for both you and others to understand and re-use your code.
“How do I prevent Facebook from kicking out my “demo” user when all the devs are logging into that account multiple times a day?”
Some people have had luck with creating that kind of account dynamically on a per use basis.
“How do you make sure unicorn restarts when running under runit?”
A project is running Unicorn under runit, and finding it doesn’t always restart when it’s told to. It seems Unicorn just isn’t responding to the signal. No one had seen anything similar.
“Can heroku_san automate the managing of my addons?”
Update to the newest version! See the github pull request
If you ever spot room for improvement or an error in the Rails documentation — and that includes the Rails Guides and the API docs — they’ve made the process extremely easy. If you’ve been waiting for “the right moment” to start contributing to open-source software, this might be it.
The docrails project on Github, has public write-access enabled so that anyone can push documentation fixes.
This Rails blog post goes into full detail on the docrails project, but here’s the short and sweet version:
If you want to expand (or just start) your “open-source portfolio,” docrails is a great place to begin.
RSVP details are included below as well. Please take the time to RSVP to the event.
Any questions on these events should be directed to the individual meetups.
Revolutionary Guard with Grant Hutchins and Ryan Ong from Pivotal Labs. As always at our tech talks, lunch is provided, but PLEASE RSVP.
Please visit the Pivotal NY Tech Talks site and RSVP if interested.
On Wednesday the NYC Web Tech Scaling meetup will be hosting their very first meetup here at Pivotal NY
Those interested should visit the NYC Web Tech Scaling site to RSVP. The event starts at 6:30PM.
Interested in hosting an event at Pivotal Labs NY?
Please contact me: email@example.com
There are many things to worry about when designing and developing for Android devices. Some of the most common questions a developer may have when entering the world of Android development are: How do we support all the different device sizes? How do we support device rotation layouts? How do we support different locales and languages?
Fortunately, Android gives us the ability to easily address these issues. Most developers have had experience using the different resource directories in their projects. For the most part, we know that images must be placed in the drawable directory, layouts in the layouts directory, and values in the values directory. Things start to get tricky when we need to accomplish more specific tasks, such as supporting high-resolution images for certain devices, or separate layouts for landscape and portrait. In order to address these unique issues, we need to create different folders for these resources. By grouping them in specifically-named folders with appropriate qualifier tags, Android will then use the appropriate resource at runtime, based on the user’s device configuration.
One of the problems I occasionally come across while using Android apps is that I see images that are blurry, pixelated, or stretched awkwardly. The solution to this problem is to create a drawable folder for each of the densities that Android supports, and place the correctly scaled image inside each folder. As of writing, there are 6 different density ranges (measured in dots per inch) that Android supports:
For current phone projects, every project should have at least 4 folders for drawables (drawable-ldpi, drawable-mdpi, drawable-hdpi and drawable-xhdpi). This allows images to be crisp and clear for all Android devices, as they won’t need to be stretched. If you are short on time, however, I have experienced that just having the xhdpi folder with assets works almost as well. These assets will be scaled down automatically on lower density devices. Keep in mind though, that low-density devices will be processing a resource that is much larger than it needs, which means it will take up more of the device’s memory.
Similarly, qualifiers exist for device orientation (port/land), platform version (v7, v8, v11, v15, etc…), language (en, fr) and many others. A full list of configuration qualifier names that can be used in Android resource folders are listed at http://developer.android.com/guide/topics/resources/providing-resources.html#table2.
So what if you want to display a different image on a high resolution device that is set to French? Short answer: create a directory in the res/ folder named drawable-fr-hdpi and place your image inside that folder. Keep in mind though, there are rules to the ordering of the qualifiers that you use for your directories. Android will search top-down based on the table shown in the link above, so since locale has a higher precedence than screen density in the table, a folder named drawable-hdpi-fr will cause an error, while drawable-fr-hdpi will be fine.
Once we have the structure set up and all assets in place, how do we use them in our project?
There are two ways that you access resources; either through code or in XML.
When you reference the resource, you shouldn’t include the qualifier(s). For example, to set the text of a TextView to a string that is located in your resources, you can use:
yourTextView.setText(R.string.your_string) in your code
or android:text=”@string/your_string” in your XML file
Even if ‘your_string’ was located in the ‘values-fr’, ‘values-en’, or ‘values-zh’, you must only use R.string.your_string, and let Android take care of the rest.
With a greater understanding of Android resource folders, you will no longer have the need to try and detect all the device properties programmatically in order to display appropriate assets/data. Using the folders properly will allow you to easily support multiple screen densities, sizes, languages and orientations quite easily and will save a lot of time and effort when done correctly.
My name is Will, I’m 30 years old, and I’m a Pivot. In my three year tenure here at Pivotal Labs, I’ve found that it may be easy to see the parts that make us successful consultants, but that forrest is hard to see for all the trees. Everything from breakfast to keybindings plays a part in making us one of the top software consultancies and the greatest place I have ever worked.
My story starts with breakfast and ends with trust. Each piece plays in to another, and the result is an environment where teams are autonomous, culture and knowledge spread quickly and organically, and communication is never a secondary priority. Our clients see the results in the way which we interact with them to deliver exactly what they need. My coworkers feel it when they realize they control their own destiny and have all the power to make their situation better. You hear it when you listen to pivots like myself or others who appear at conferences across the globe. What we have here is special.
We have breakfast prepared for us by an outstanding catering staff. It is delicious and you should be jealous if only because it means that there’s one less thing I have to do in the morning. It isn’t just food though, and it isn’t a ploy to eek out more hours from pivots like other companies that might provide dinner in hopes that you don’t leave till midnight. No, breakfast is much deeper than eggs and bacon – it’s a time to cross pollinate, to talk to the pivots who aren’t on your team to share in things both work and non-work related. It also gets us to the office at the same time, which makes it easy to pair together for eight hours, then we all go home together at six, and breakfast leads us right in to our all company standup.
Yes, the whole body of developers participate in the biggest, most high value standup you’ve ever seen. At pivotal you’re never alone, and company standup is just one of the ways we assure that is always true. When you have hired the best (more on that later), why wouldn’t you want them all to be on every team all the time? Since mitosis of humans hasn’t left science fiction yet, we have to settle for osmosis. We go over who is new or visiting the office, who needs help, and what interesting stuff has come up that might be relevant to other teams. You can read our standup notes right here at pivotallabs.com/blabs. Culture starts here too. Company jokes develop over time as we all gripe about the bumpy release process a particular tool is going through. Company standup also makes it clear that it is okay to not know things. Let me say that again: It is okay to not know something.
Another pivot, Davis Frank, shared an analogy that resonated, but since my Bruce Lee knowledge leaves most wanting, I have adapted it to a much geekier Star Trek take. Being a pivot is akin to being a senior officer on the bridge of the Enterprise. We hire people who will speak up and collaborate, people who will work to make exploration sustainable. We all come to Pivotal Labs with our own expertise like Jordi with his engineering skills, and Beverly the medical doctor, but the very nature of working with startups and our other clients means that we are always going “where no one has gone before” with respect to code, and sometimes the ship’s councilor has to hot wire a tricorder. There is no manual on how to build Twitter or Groupon. Pivotal never gave me the answers to those problems, that’s not how we work. Instead, Pivotal, like Star Fleet, exposed me to a lot of problems all the time and gave me the resources and teams to help me solve them as I encountered them.
After company standup and our own team standup, we pair program. That means two people, one computer, all day. It isn’t half as radical as it may seem at first glance. Has anyone at your standups ever asked for help? Did someone then go over and sit with that person at one computer? I suspect they did. Do you do code reviews? Then aren’t you really asking your team to share coding knowledge and culture? Think about it. This is what pairing is all about, we’re just set up to do it a lot more often. And getting back to trust, pairing turns a potentially threatening code review process in to a co-ownership process.
Pairing builds trust in all directions. It builds trust between the pair and the client accepting the user stories because I know that two people have thought about this problem. I also know that any cultural nuances that one pivot has picked up are being shared inline with the other pivot. Pairing builds trust between devs. If you talk about code with someone for eight hours a day you can’t help but understand how he approaches problems. That said, you may not always agree, but at least you understand, and you can have much deeper, more meaningful collaborations when that understanding is in place. Pairing develops trust between the team and the individual because I know that if a feature fails, I am not alone in the failure, and if the feature succeeds, I will have good company to celebrate the success.
Talking about code for an entire work day is hard, I won’t pull any punches there. Think about the last time you were in a long white boarding session. I might have been needed, and possibly energizing, but I bet you also needed to decompress for at least fifteen minutes after. Pairing is like that, so we find other ways to communicate that also happen to feed in to the trust: Test Driving. Write tests first; that way, as your pair, I know what we’re about to work on for the next five to twenty minutes. Writing tests first is a great way to enhance your pair’s understanding of how you’re thinking about a problem and the potential solution. Once you have the test, it has the added benefit of speaking to future devs who might work on this code and communicate what it was meant to do so they can make an informed decision whether you’re available or not. Speaking of which, since we rotate between projects, someone not being there is more than just a possibility, it’s just a matter of time.
Rotation is a razor sharp double edged sword. Your average dev working for a product company might switch teams once in three years. Meanwhile at Pivotal Labs, I’m seeing new problems and new solutions at a rate 3-6 times that. It means that I can demonstrate loyalty by staying at one company, but the experience of working for ten companies in that same timeframe. Rotation makes our best pivots that much better. The downside of course is that someone who demonstrates loyalty but possesses the experience that is characteristic of a senior pivot soon finds himself being invited to take on lucrative and dazzling roles elsewhere. I can’t begin to explain the sadness and frustration I feel when a pivot leaves the company, but we also can’t afford not to train up our employees. It is the same high quality that makes pivots hirable that brings in the steady stream of clients to Pivotal Labs. If we stunted or slowed that growth any way, it would weaken our offering in a way that would undermine much of what is good about Pivotal Labs.
We are unwavering when it comes to hiring. When you come in for an interview, you write code on real product because that’s what we’re expecting you to do when you’re here everyday, not solve brain teasers at some white board. We want to know if you can communicate, and we want to know if you can learn and adapt. Pivotal throws pivots in to uncharted waters a lot and we expect pivots to swim. They always do because we hire great swimmers. Hiring great people means we don’t have to spend a lot of time with formal training, or managing, because people are good citizens within the company. Also, hiring great people who raise the average and are put in a place where they pair and rotate means that the average really does go up for everyone. This has an awesome effect on morale, and serves to give us all the confidence that we need to takle new problems. Having the best means that teams can be autonomous and we can trust them to interact directly with the client eight hours a day. We don’t have any need for the “heros” or the “ninjas” who can strap on headphones and have a caffeine-induced flow session. We hire largely for technical aptitude and ability to communicate which is not most developers. When you’ve hired the best for this business, delivering features comes naturally.
The real magic of Pivotal Labs that you might not notice at first is Pivotal Tracker. It may look like an ordinary project tracking system, but it does two things very well that most software fails to do: 1) Tracker forces clients to prioritize the work we do for them, and 2) it serves as a central communication piece. The former is very important to the success of the project. I’d like to think that because of all the other things we do, we produce more features period, but that’s not the whole picture. Because everything is prioritized, we produce the right features, or at least the features the client wants the most. It is hard for a client to be dissatisfied when we’re always working on the most important thing. We know it is the most important thing because we’ve talked about it. Tracker is the main talking point in our short, weekly meeting so we know that our client wants these features first, we talk about any technical needs we have on our side, and discuss the story details beyond what is typed in Tracker. Remember how I said it all plays in together? Well since we all sit together, and we all trust each other, it greatly reduces the need to spec out every last detail – most of the time we have enough context to make well informed decisions, or we can turn around and ask our client for clarification, or baring that we deliver a story and get some great feedback in the form of a rejected story. At Pivotal, you’d have to work really hard to not deliver what the customer wanted.
Being an Agile shop means we’re always gathering feedback and looking for ways to do our job better. Each project is different, so we have regular retrospectives to help us surface and adapt to those differences. This exercise is focused on getting better, and depends on honesty and therefore builds trust in a team. This goes hand-in-hand with hiring the best, because the best speak up and the best aren’t afraid to say something scary or controversial. The best lay their ego aside in order to improve a team, project, or a company. I strongly believe that, if left alone, the right people with retrospectives would arrive at a process that looks a lot like Pivotal Labs does today – in fact I would argue that’s what happened when the idea of Agile was first put to paper by Beck, Fowler and the rest of the Agile work group. Get and give feedback, act on that feedback, that’s the core. Action however, doesn’t always lead to success at first try.
In fact, taking action leads to failure a bunch. Since the set of problems, both human and technical is huge and enormously complicated, it is reasonable to assume that most guesses at actions would end in failure. But guess what, we fail, get feedback, take action, and over time, those actions lead to successful actions. Often times the success is very different than it was originally pictured. We also have the benefit of having that experience that can now be applied to a future project. Pivotal Labs is good about making it safe to fail. Read that again, it is safe to fail here. Why? Because we start with the best, then we give them a lot of experience, and we trust them to make the best decision given the information and experience they have. And because we’ve hired for it, teams own their failures, and they’re intrinsically motivated to do better. No one has to sit over their shoulder and tell them it went wrong. They know, and as a matter of pride they’ll fix it. Most importantly, they have the skill set and the resources to fix it.
By now you should be hearing it in your head, that it all feeds in to itself. The whole thing works because it is complete. Each part, start time, pairing, test driving, hiring, clear priorities, and feedback contribute more to the system than just its stand-alone value. The pieces are all obvious, but how they interrelate and build trust across the organization is what makes Pivotal an outstanding company. My name is Will, and this is why I’m a pivot.
If you’re looking for developers, and you want to get the most important things done, I hope you’ll consider becoming one of our clients, we do web and mobile work and you can drop us a line at firstname.lastname@example.org. If this resonated with you and you’re looking for a job as a developer, please send your resume to pivotallabs.com/jobs.
Max has an almost-there solution that he sent out to the mailing list:
module Jasmine class Config def src_files Rails.application.assets["application"].dependencies.map do |asset| "assets/" + asset.logical_path end end end end
“I’m looking for a client-side JS syntax highlighter!”
That slowness when you start Terminal? It’s parsing through all your system logs to figure out when the last log-in occured. Speed up your terminal with
http != https — who knew? Turns out sending an AJAX post from a non-secured origin (http) to a secured end point (https) smacks agains the same-origin policy. Solutions?
In Rails 3.1 and newer, when you write a migration by hand, you can (usually) just define a
change method instead of an
up and a
class RenameOldTableToNewTable< ActiveRecord:Migration def self.up rename_table :old_table_name, :new_table_name end def self.down rename_table :new_table_name, :old_table_name end end
class RenameOldTableToNewTable< ActiveRecord:Migration def change rename_table :old_table_name, :new_table_name end end
What’s the best way to think about redirects for API calls? e.g. You post to create an object, what should you get in return?
The crowd: Some concensus emerged around: send back a 201 with a location header pointing to the url for the object and a body containing the object itself.
Mongoid’s atomic operations don’t trigger hooks (before_save, after_save, etc…)
The crowd: Crickets…
haproxy, like nginx, can pass http connection through with the header ‘X-Forwarded-For’ set so that it is possible for the app to know the original client IP. But haproxy doesn’t have support for serving as an SSL endpoint, so https:// connections are proxied in tcp mode instead of http mode. And no headers can be added because the request remains encrypted.
Terminate the SSL connection in front of haproxy. PIvots suggested doing this via an additional nginx instance. Online resources show how to do this using stunnel. (http://www.completefusion.com/ssl-load-balancing-with-haproxy-and-stunnel-on-debian/)
Use nginx as the load balancer and discontinue using haproxy, or find a load balancer that fully supports SSL.
Build HAProxy with TPROXY support. http://blog.loadbalancer.org/configure-haproxy-with-tproxy-kernel-for-full-transparent-proxy/