Paperless Post’s series of tech talks continues next month with a talk by Chrys Wu. Chrys will be speaking about “The Role of Data & Design In Engaging With An Audience” on Tuesday, August 5th at 7pm at the Paperless Post offices.
Chrys Wu, a journalist, strategist, coder and cook, works with businesses to deepen connection to people through community-building strategy, user-centric design and code.
She is currently Developer Advocate for The New York Times, where she leads internal and public-facing projects that advance and highlight the technology made by New York Times Developers.
If you would like to attend the talk, please RSVP and make sure to bring a photo ID to check in with building security.
About Paperless Post Tech Talks
Paperless Post Tech Talks are our chance to bring developers and artists whom we admire into our New York office to talk and share knowledge about their work with our team and the larger New York tech community. They are open to the public but RSVP is required as space is limited. There will be time to talk and mingle with the other attendees and the speakers over craft beer and snacks.
Paperless Post’s series of tech talks continues this month with a talk by Ken Perlin. Ken will be coming to speak about “Early Experiences and Current Influences in Computer Graphics” on Thursday, June 26th at 7pm.
Ken is a professor in the Department of Computer Science at NYU and the Founding Director of its Media Research Lab, as well as the Director of the Games for Learning Institute. He invented Perlin noise and was involved in the development of many early influential computer graphics techniques.
As a System Architect for computer-generated animation at Mathematical Applications Group he worked on the movie Tron and has received an Academy Award for Technical Achievement. We’re thrilled to have him come talk to us about the path he’s taken and connections between the earliest days of computer graphics and today.
If you’d like to attend the talk, please RSVP and make sure to bring a photo ID to check in with building security.
About Paperless Post Tech Talks
Paperless Post Tech Talks are our chance to bring developers and artists whom we admire into our New York office to talk and share knowledge about their work with our team and the larger New York tech community. They are open to the public but RSVP is required as space is limited. There will be time to talk and mingle with the other attendees and the speakers over craft beer and snacks.
A few weeks ago, I had the pleasure of speaking at BACON about working with our main rails codebase. It was a lot of fun sharing a bit of our process with such a great conference. A video and my slides are below.
Every talk I went to at the conference was interesting and informative. They are all available at BACON’s site if you want to see more!
Last month, two of us attended RailsConf in Chicago. There were so many great talks, and we had a great time meeting lots of other developers from around the world. Here are a few of the amazing talks that we saw:
I had never heard of mutation testing before, but came away with a really great understanding of the idea as well as how to use this specific library. Essentially, mutant changes your code at runtime, and asserts that some test fails with that change. For example, if you have a conditional like
1
ifa&&b
mutant will change it to
1
ifa||b
If you have proper test coverage, when b is false and a is true, some test for this method should fail. It’s a great way to better measure your test coverage.
Technical Onboarding, Training, and Mentoring - Kate Heddleston
This talk reminded me of how good of a job we already do onboarding people here at Paperless Post, but gave me the idea to formalize and document the process better. Kate makes a lot of great points; I especially liked the idea of journaling, giving a new hire a place to keep and share thoughts in their first few weeks.
Sandi Metz’s talks are always great. In this talk, she goes through refactoring some complicated code into smaller, better parts. There were a few key takeaways that I really liked. First is The Squint Test: Sandi suggests that the complexity of code can sometimes roughly be measured by observing the changes in shape and color. Things with greater variation of indentation will likely be more complex. The second is that refactoring might introduce more complexity in the interim. Sandi didn’t shy away from making the code a little bit more complex as she worked toward her solution, knowing that she would be able to reduce that complexity towards the end of the process.
Andrew Warner explores an interesting concept on how to handle views in a web application. There are several ways one could render views. For single page thick client applications, the view is written in javascript while the server returns data. For document based applications, the server renders full HTML pages. There are pros and cons for each option but if you were to implement an application that uses both solutions, you would end up with duplicate views - one on the server and one on the client. Perspectives is a gem that helps solve this issue. The underlying concept is that Mustache is used as the lowest common denominator and Rails can render either the full HTML page or the JSON to populate the template.
This talk explores tools and techniques when your Rails application begins to turn into a SOA client. One of the biggest takeaways I got from this talk is the concept of middlewares in Rack and Faraday. I knew previously that middlewares are like mini-Rack applications that can modify the request as it comes in from the server or the response as it comes out of our Rails application. Similarily, Faraday operates in the same fashion but in the opposite direction. There are middlewares that can modify the request before it goes out and the response before it comes in.
Class Reloading in Ruby on Rails: The Whole Story - Xavier Noria
This talk gives a brief overview of Ruby constants the three algorithms Ruby uses for looking up constants. Then, Xavier Noria contrasts Ruby’s lookup with how Rails loads constants and how it implements autoloading. This was quite an in-depth techincal talk and I recommend watching this if you want to take a dive into constants and Rails reloading. Some of the things I learned include: Module.nesting, require_dependency, and constant tables being stored in the Module instance objects.
This post continues our series on Stampy Day, a company-wide hack day here at Paperless Post. We hope you enjoy reading about some of the projects that came out of that day.
Last year we set out on an ambitious project to phase out our interactive flash based “create tool”, replacing it with JavaScript and HTML5. The platform we were initially targeting wasn’t the web, but instead our native iOS app. This was a move that would allow us share a common code base and feature set across all platforms.
The “Viewport”, as we call it, is written entirely in JavaScript, and was headed up by @talltyler. On the iOS sides of things, we immediately found that the Apple provided UIWebView which is capable of executing JavaScript wasn’t the right tool for the job (for numerous reason). We were fortunate enough to find the open source project Ejecta, which is a self described “Fast, Open Source JavaScript, Canvas & Audio Implementation for iOS.”
During development, the majority of JavaScript debugging occurred at the browser level, using the debug console in chrome and safari. This often left things to chance when we ran them in iOS. For Stampy Day this year, we decided to address that issue by building a remote debug-console for iOS + JavaScript. On the web side of things, @talltyler built a web app that we run on our Mac Mini build server. The web app uses sockets via Socket.io, and can host multiple clients simultaneously. On the iOS side of things, we are also using a Cocoa implementation of Socket.io to connect with the server. Once a connection has been established, you can access any device from the web app and start debugging! Debugging works just like you would expect: type in some javascript, send it, and BOOM, fresh console output.
On iOS we created a special subclass of our “javaScriptView” that is instantiated in debug mode as a cluster class. Once you have the viewport up and running, connecting is easy:
Whenever the web app sends in JavaScript, our delegate receives a callback, evaluates the JS, and returns the result if a callback is requested
123456789
- (void)remoteConnection:(PPJSRemoteConnection *)connection didReceiveMessage:(PPJSRemoteMessage *)message requestedCallBack:(void (^)(NSArray *args))callback
{
NSString *js = [message javaScriptToBeEvaluated];
//debug_eval has the JSContext execute the provided JavaScript and return a value, if any
id returnValue = [self debug_eval:js]? : [NSNull null];
if (callback) {
callback(@[returnValue]);
}
}
Thanks to the dynamic nature of JavaScript, we are able to diagnose issues, update code, and fix bugs in real-time without the need to rebuild the iOS app or JavaScript file.
Dev Blog
