http://www.9to5mac.com/38336/cydia-hack-enables-airplay-in-all-apps

This is huge, and it's likely that Apple will enable this for themselves in an iOS update at some point.  I can't count how many times I've browsed video on my laptop with others around only to wish I could throw it onto my TV.

The more I think about it, could we have a future where TVs don't have inputs?  They would be simple streaming clients to which other devices push content.  You've got your phone with you - why would you need anything else?

~s

I've got a Mac project I'm working on that required a scalable viewport into another view.  Because the viewport could be a scaled version of the target view, it also needs to be scrollable.  This sort of pattern is seen a lot in editing applications and web browsers.  Specifically, I was looking to mimic the iPhone Simulator app.  It took me about 10 hours of wrangling cocoa to get it to do what I wanted.  I tried writing a custom NSClipView among other tactics, but what I found to work in the end was pretty simple.  This technique should transfer to iOS readily.

To scale the view you're inspecting, you'll likely use NSView's scaleUnitSquareToSize: selector.  This will render the view's contents using Quartz scaling algorithms.  However, it will not change the frame/bounds of the view.  This is where the crux of the problem lies - the scroll extents of the scroll view would not change.  When scaled up, the scroll view would not scroll enough of the view to see all of it.  When scaled down, the scroll view would scroll too far and show emptiness on the sides of the document.

To work around this, we will create a new document view that advertises the correct frame to the scroll view.  It will host the true document view as a subview, without clipping it and without autoresize enabled.  It will monitor the document view's frame and adjust accordingly.  It will also need to know the scale of the document view, and the easiest way to handle that is to have this new host view control the scale of the document.  Here's all the code you need:

https://gist.github.com/715903/e11a0afe4245fa697e5660d4fc887eae08275bec

Once you have this code, you can call setDocumentView: on any scroll view with a HostView.  When you need to change the scale, call setScale: (or use the property accessor) on the HostView.  The scroll view will adjust its scroll bars accordingly.

Note, however, that the scroll view's frame will not change - the scroll view's size will be the same, but the scroll bars will reflect the correct amount of data that is visible.  If you want the scroll view to adjust its size correctly to fit the document, you will need to add some more monitoring to the document's frame size and adjust accordingly outside of the scroll view itself.

~s

I read this article today about creativity and its lack of existence in American education. It reminded me of many things, but foremost got me thinking about how the various projects I’ve worked on have attempted at codifying creativity.

In the article, creativity is described as the ability to think divergently (generate ideas), and then converge on something (combine those ideas into one). I’ve never heard a more succinct definition that is applicable to so many situations. Of course, I look at this from the angle of building software & hardware.

Engineering is a creative process, but we rarely recognize the need for divergent thinking. We all expect big engineering companies to come up with new and innovative solutions for the problems we have in our daily lives, and management loves to get a team of engineers fired up about solving those problems. However, organizations also get very anxious when the team shows little progress towards building an actual product over an extended period of time. Management can get especially antsy when the goal was to have a product out by the end of the year, but it’s March and you don’t even know what features it will have yet.

The projects on which I have worked have sandboxed creativity to designers. Sure, engineers could consider themselves creative people, but they didn’t get to practice creativity in the way the article suggests. Everything had a schedule associated with it, and even prototypes and investigations were time boxed. The article talks about disengaging the left side of your brain to get some right brain action started. I find that, under schedule pressure, this is very difficult to do.

Larger problems need larger playgrounds for divergent thinking and experimentation. On one scale, the divergence in opinions about social networking had lots of competitors (Friendster, MySpace, Orkut, Facebook). If we think of the introduction of these products into the market simply as divergent thinking, it took maybe a decade for things to converge. On yet a larger scale, the divergence in opinions about how to build software (open source, closed source, somewhere in the middle) has been in experimentation for 20 years and continues.

At Microsoft, many groups move from the tail end of implementation in a release to the beginning of implementation in the next release. There are planning phases that are supposed to allow for creativity, but I just don’t think it’s enough. The Xbox release before last had a 3 month planning cycle, but it lacked real convergence. The last project I know of that truly had the wave of divergence & convergence before it began implementation was Courier: it started with designers looking at the act of reading, only to find that reading leads to writing. It took over a year and a half to converge on what would eventually become Courier.

I’m still not sure how to use this new information: creating a process to spur creativity seems ironic as processes usually stifle divergent thinking.

~s

http://www.ifixit.com/Teardown/Microsoft-Kinect-Teardown/4066/1