How to decrypt iPhone backup

I screwed up my iPhone today. the backup was corrupt and could not be restored. to make the matter worse, backups were encrypted as well.

Fortunately, I did know my encryption password. there are a few apps out there supporting encrypted iPhone password, but they are all paid apps. My inner hacker told me to do it yourself. So, I did. Enjoy!

Requirements:

  • Xcode. remember to install command-line tools in preferences
  • ldid
  • Python 2.7 (or 2.6) : for building a custom kernel and computer-side tools. Python 3 is not supported.
  • pycrypto
  • M2crypto
  • construct
  • progressbar
  • iPhone-dataprotection

Read More

HTML link tag hack sends you to the wrong place

[shared via Google Reader from Hack a Day]

hacking-html-a-tag

We consider ourselves fairly cautions Internet warriors. We know when to watch out for malicious links and tread lightly during those times. But this hack will still bite even the most cautions of link followers. It’s a hack that changes where a link is sending you after you click on it.

The concept is driven home right away by a link in the post which lists PayPal as the target when you hover over it with your mouse. Clicking on it will give you a warning that it could have been a malicious page you were redirected to. Of course the address line of the page shows that you were sent somewhere else, but it’s still an interesting issue. The hack is accomplished with just a few lines of JavaScript. In fact, the original example was 100 characters but a revision boils that down to just 67.

So who’s vulnerable to this kind of thing? It sounds like everyone that’s not using the Opera browser, which has been patched against the exploit. There are also some updates at the bottom of the post which mention that Firefox has been notified about it and Chrome is working on a patch.

[via Reddit]


Filed under: security hacks
tallmanbusiness

The tools entrepreneurs need to make a great pitch to potential investors.


image

Last week was a momentous week for the whole team in the London Wayra Academy - it was our Demo Day on Wednesday.

I am hugely proud that all the teams did a brilliant job of pitching their unique businesses to an amazing group of over 100 investors with the objective of securing future funding.

A while ago I started drafting a brief post on what makes a great pitch - initially I felt really strongly that two important ingredients are fundamental to a good investor pitch:

  • Passion
  • Practice

Passion, because the challenge of being a successful entrepreneur is nuts - it’s like waking up and saying you’re going to climb Everest. And so if anyone is equally nuts enough to invest their hard cash into your endeavour, they’ve got to believe that you’ve got what it takes to reach the summit.

Practice, because, one of the privileges of working at Wayra is that I get to hear pitches from entrepreneurs from all over the world. While some of the newest teams pitch brilliantly, it is an indisputable fact that the teams that joined Wayra at the beginning present more powerfully as direct consequence of literally having pitched many more times. There is no short-cut to pitching 1,000 times.

Two vital ingredients, both more important than the microphone and a clicker suggested by my photo. But now the presentations are completed, I think that success in pitching for investment requires much more. My broader thoughts are:

Preparation. It is so important that entrepreneurs obtain quality input from experts into crafting their pitch-deck. For example, feedback from experienced entrepreneurs and investors. And most importantly, entrepreneurs should actively seek and exchange constructive feedback with their peers. Which is why I believe the ‘Wayra-family’ is arguably the most valuable component of the acceleration programme. And why I’m also a fan of ‘Don’t Pitch Me Bro’.

Talent. Sounds obvious really - it also sounds uninfluenceable - but it is: practice helps; but more effective is who you choose to pitch. I find it remarkable that entrepreneurs often feel it is both their right and privilege to lead the pitch whether or not they are the best presenter. It is not incumbent on the founder to pitch, it is incumbent on the founder to ensure that the best pitch is delivered.

Authenticity. Never confuse talent with ‘slickness’ - slickness can actually camouflage talent. What investors want to see and hear is authenticity.

A good story. Your pitch needs a clear ‘beginning’, ‘middle’ and ‘end’. Fundamentally, the context - why are you doing this. It’s about demonstrating why your business is a good idea, and why you are overwhelmingly driven to pursue it. The combination of which needs to leave the unmistakable confidence that despite your ambition being (possibly) ridiculously impossible, there is real belief that you are actually going to conquer this mountain.

Evidence that you will harness the power of digital:

  • To acquire customers in volume, and at pace - contagiously via viral marketing; effective use of social-media; and/or search/SEO compatability
  • To use the accumulation of customer data effectively for the customers’ advantage

A willing audience. Take responsibility for driving attendees. And your behaviour will determine how ‘willing’ they are. Smile; use humour appropriately; establish rapport. 

Know your numbers. Opinion is divided on the validity of financial projections in pitches. However, know your numbers (inside out and backwards).

Up-and-to-the-right-graph” - feedback from one of the investors advised that this is currently hot in the US - a slide/graph that evidences demonstrable quantifiable momentum - whether that is financial; registrations; downloads etc etc. It not only evidences traction, it also clearly illustrates the key focus of the CEO. It doesn’t matter if the stats are ‘usage’ related (and not financial) - if there is traction then investors will believe the revenue will follow.

Talk about your team, but not for too long. In one sentence, what makes you special.

Make the right request - especially if you’re asking for investment. The amount of money that you are looking to raise is an especially important issue - and so I will write a separate post on this specifically.

Congratulations to teams who did such a brilliant job pitching. Congratulations also to Ashley Stockwell and Alex Hawkes who have done a remarkable job of managing the London Wayra Academy.

Sincere thanks to Wayra’s expert coaches and mentors who helped the entrepreneurs to refine and finesse their pitches - especially the immensely talented Dale Murray.

Thanks also Ash for taking the photo of my hands, charged and loaded with two tools of our trade: microphone and clicker - moments before the investors took their seats for our introduction to a full day of pitches. What a great day.

Source: Simon Devonshire’s blog



Rogue Pi: A RPi Pentesting Dropbox

[shared via Google Reader from Hack a Day]

Rogue Pi

A pentesting dropbox is used to allow a pentester to remotely access and audit a network. The device is dropped onto a network, and then sets up a connection which allows remote access. As a final project, [Kalen] built the Rogue Pi, a pentesting dropbox based on the Raspberry Pi.

The Rogue Pi has a few features that make it helpful for pentesting. First off, it has a power on test that verifies that the installation onto the target network was successful. Since the install of a dropbox needs to be inconspicuous, this helps with getting the device setup without being detected. A LCD allows the user to see if the installation was successful without an additional computer or external display.

Once powered on, the device creates a reverse SSH tunnel, which provides remote access to the device. Using a reverse tunnel allows the device to get around the network’s firewall. Aircrack-ng has been included on the device to allow for wireless attacks, and a hidden SSID allows for wireless access if the wired network has issues. There is a long list of pentesting tools that have been built to run on the Pi.

Check out a video demonstration of the dropbox after the break.


Filed under: Raspberry Pi, security hacks

The Basics of Caching and Cache Digests

[shared via Google Reader from RubySource]

This is an introduction to caching in Rails.  You may know that Rails performs some caching “automagically”, but you aren’t quite sure what that means or what that is. Read on to find out.

In a nutshell, caching gives us quick access to values without hitting a more expensive store, such as a database. In this manner, we can improve the performance of our Rails app. Rails will cache almost anything, from an object to a page to a partial.

Rails mainly provide three techniques of caching.

  • Page caching
  • Action caching
  • Fragment caching

Before we get started, be sure you have enabled caching in your environment file.

config.action_controller.perform_caching = true

It’s true by default for production.rb but false for development.rb and test.rb.

Page Caching

Page Caching is a mechanism which stores the  output of an action in a file. so when a request comes in the web server can respond without going through Actionpack . To try this out, I have created a sample application . I generated a scaffold blog with title and  description attributes. In our blogs controller, we have an index action and we want to cache that.  To accomplish this, call caches_page method for the action we wish to cache.

class BlogsController < ApplicationController
  caches_page :index
  def index
    @blogs = Blog.all
  end
end

Rails create a file in the /public directory called blogs.html  When we start our server and make a request for ‘/blogs’, Rails caches the first vist to the page in the aforementioned blogs.html file.  Any time after that, you will see that cached file, as shown in the following log entry:

Write page /Users/rashmiyadav/crap/cache_digest_test/public/blogs.html (0.7ms)

If you want to cache another action, just add it to method caches_page

caches_page :index, :show

In order to expire the page so we can cache a new version, issue a call to  expire_page:

class BlogsController < ApplicationController
  caches_page :index
  def  index
    @blogs = Blog.all
  end
  def create
    expire_page :action => :index
    @blog = Blog.new(params[:blog])
    @blog.save
  end
  def update
    expire_page :action => :index
    @blog = Blog.find(params[:id])
    @blog.update_attributes(params[:blog])
  end
end

Anytime we update or create a record it will expire the index cache. You can validate this, again, using the logs :

Expire page /Users/rashmiyadav/crap/cache_digest_test/public/cache/blogs.html (0.2ms)  

The expire_page method takes a number of arguments, such as  the path of cached page like ‘/blogs’, or a hash with action, controller name, and format to expire.

 expire_page :controller => 'blogs', :action  => 'show', :format => 'json'

Configuration

By default, Rails stores cache files in the /public directory, but we can change it. Simple change the page_cache_directory value in config/application.rb file:

config.action_controller.page_cache_directory = Rails.public_path + "/cache" 

Now all cache files will be in the /public/cache directory. One thing to remember, if you are running the server locally in development  and you have old cache files in you public directory, the server will continue to pick up the old cache files in the public directory. In other words,  don’t forget to remove the old cache files from the public directory.

Another configuration item for page caching is the extension of the cache file. The extension of a cache file depends on the incoming request. If it’s json, then cache file will be ‘.json’ and if the request is xml  then the cache file will be ‘.xml’ and so on. If a request does not have any specific extension then, by default , it will get a ‘.html’ extension. We can configure this using config.action_controller.page_cache_extension.

Page Caching is one way to speed up your application, but it is not an option if you have content that sits behind authentication.  Let’s look at the other methods of caching in Rails.

Action Caching

Action Caching is similar to Page Caching, except that filters are executed before the caching occurs. Let’s take our blog application example:

class BlogsController < ApplicationController
  before_filter :authenticate
  caches_action :index
  def index
    @blogs = Blog.all
  end
end

we call caches_action in order to cache the  index action. The first time we hit the link http://localhost:3000/blogs results in the following blog entry :

Write fragment views/localhost:3000/blogs (1.8ms)

Now, every time we call the index action,  it  will run the authenticate method before giving the cached response.  This is the main difference between action and page caching . Action caching runs all the filters before serving cache.

Expire the Cache

To expire the cache, we just need to call expire_action:

class BlogsController < ApplicationController
  caches_action :index
  def index
    @blogs = Blog.all
  end
  def create
    expire_action :action => :index
    @blog = Blog.new(params[:blog])
    @blog.save
  end
  def update
    expire_action :action => :index
    @blog = Blog.find(params[:id])
    @blog.update_attributes(params[:blog])
  end
end

When we update and create a record, it will expire the action cache.  Here’s the corresponding log entry:

Expire fragment views/localhost:3000/blogs (59.0ms)

The expire_action method takes the same arguments as expire_page above:

expire_action(:controller => :blogs, :action => :show, :id => 25) 

Configuration

If we need to cache an action based on some conditions, we can do that by using :if or :unless with a proc. For example, if we don’t want to cache the index action for json requests:

class BlogsController > ApplicationController
  caches_action :index, :if => Proc.new{|c|!c.request.format.json?}
  def index
    @blogs = Blog.all
    respond_to do |format|
      format.html # index.html.erb
      format.json { render json: @blogs }
      format.csv
    end
  end
end

We can also configure the default cache path.

caches_action :show, :cache_path => { :project => 1 } 

If you pass :layout => false, it will only cache your action content. It is useful when your layout has dynamic information .

Fragment Caching

Page caching and action caching both cache an entire page or an entire action,  but what if we just need to cache a part of a view? This is where fragment caching comes into play. We usually have a view with dynamic content, so we can’t store the whole page.  However, it is likely that we can cache bits of the page and expire them as needed.

If we are showing a blog post with their comments, we can cache the comments by themselves:

<div>
  <%= @blog.title %><%= @blog.desc %>
</div>
<%cache("blog_comments_#{@blog.id}") do%>
  <h3>Comments</h3>
  <% @blog.comments.each_with_index do|c, i|%>
    <div><%= c.value%><span><%= c.created_at.strftime('%B %d %Y')%></span></div>
  <%end%>
<%end%>
<%= link_to 'Add New comment', new_blog_comment_path(@blog)%>

The comments section should be changed when adding a new comment, and we are caching them with the key “blog_comments_#{@blog.id}”). Here is what the log says:

Write fragment views/blog_comments_1

Expire Cache

To expire this cache, call the expire_fragment method . Here, it is called when a new comment is created:

class BlogsController < ApplicationController
  def create
    @blog = Blog.find params[:blog_id]
    expire_fragment("blog_comments_#{@blog.id}")
    @comment = @blog.comments.new(params[:comment])
  end
end

Configuration

If a key name is not provided to the cache function, then Rails will cache the block based on the name of the controller action. In this case, you would expire the cache by calling expire_fragment(:controller => ‘blogs’, :action => ‘show’).

This, obviously, will generate conflicts if

  • We also caching action
  • And  having  multiple fragment cache per action

We can add an action suffix to avoid such conflicts:

cache(:action => 'show', :controller => 'blogs', :action_suffix => 'blog_comments' )

To expire this cache:

expire_fragment(:controller => 'blogs', :action => 'show',:action_suffix => 'blog_comments')

Sweepers

Calling an expire method inside a controller action is a bad idea.  Rails provides another mechanism for this expiration process:  Sweepers. Sweepers are responsible expiring caches . They observe models and execute callbacks as defined in the sweeper.

For example I created a blog_sweeper.rb file:

class BlogSweeper < ActionController::Caching::Sweeper
  observe Blog
  def after_update(blog)
    expire_action(:controller => :blogs, :action => :index)
  end
  def after_create(blog)
    expire_action(:controller => :blogs, :action => :index)
  end
end

But we need to  call this sweeper in our controller for this call cache_sweeper method in controller

class BlogController < ApplicationController
  cache_sweeper :blog_sweeper, :only => [:index]
end

Cache Digests 

Cache digests are a better way to handle  fragment caching. It’s based on a Russian Doll  scheme, meaning, when you have nested cached fragments and the nested content changes, only expire the cache for that content reusing the rest of the cache. Here is an example from our same blog application. Our model structure look like :

class User < ActiveRecord::Base
  has_many :blogs
end
# Blog model
class Blog < ActiveRecord::Base
 has_many :comments
 belongs_to :user, :touch => true
end
#comment model
class Comment < ActiveRecord::Base
 belongs_to :blog, :touch => true
end

We are using the touch option here so if we update a comment, the blog will get a new updated_at value.

Here is the ‘users/show.html.erb’, showing user’s detail with their blog and comments:

<%cache @user do%>
  <div>  Name:<%= @user.name %></div>
  <div>  Email:<%= @user.email %></div>
  <%= render @user.blogs%>
<%end%>
<!-- 'blogs/blog.html.erb' -->
<%cache blog do%>
  <div><%= blog.title %></div>
  <div><%= blog.desc %></div>
  <%= render blog.comments%>
<%end%>
<!-- 'comments/comment.html.erb' -->
<%cache comment do%>
  <%= comment.value %>
<%end%>

You can see that we cache the comments inside the blog and the blog inside the user. In an example where we have a single user with 2 blog posts and 1 comment, the cache keys look like:

views/users/1-20130118063610
views/blogs/1-20130118063600
views/comments/1-20130118063600
views/blogs/2-20130118063610

It is a combination of view path, object id, and timestamp of the last time it was updated. This combination ensures a cache will always be expired if a model is updated. If we add a new blog or edit a blog it will expire the cache of user along with blog cache. because we have used touch option in our blog model.

Likewise, if we add or edit a comment, everything expires. However, if we change any thing in the view itself, such as a new style, reloading the page will not reflect the change as our cache keys are not expired. We can mitigate this by keeping a version of the cache keys and changing that version as needed.

<%cache ['v1', @user] do%>
  <div>Name:<%= @user.name %></div>
  <div>Email:<%= @user.email %></div>
  <%= render @user.blogs%>
<%end%>
<!-- 'blogs/blog.html.erb' -->
<%cache ['v2',blog] do%>
  <div><%= blog.title%></div>
  <div><%= blog.desc %></div>
  <%= render blog.comments%>
<%end%>
<!-- 'comments/comment.html.erb' -->
<%cache ['v3',comment] do%>
  <%= comment.value %>
<%end%>

Every time we modify our view, we need to update the version of the cache key. Now we have more problems:

  • We need to remember the version number of the template
  • Parent template versions should be changed if child template is modified.
  • If the same partial is used in different  views, then it hard to maintain versions

Don’t panic!  Rails always tries to make thing simpler. In Rails 4, cache_digests have been added to maintain nested fragment caching.

With Cache Digests, we actually don’t need to worry about expiring caching and versioning  when we have nested fragment caching.  By the way, you can use cache digests in Rails 3.X by adding the cache_digests gem to your Gemfile.

<%cache @user do%>
  Name:<%= @user.name %>
  Email:<%= @user.email %>
  <%= render @user.blogs%>
<%end%>
<!-- 'blogs/blog.html.erb' -->
<%cache blog do%>
  <%= blog.title %>
  <%= blog.desc %>
  <%= render blog.comments%>
<%end%>
<!-- 'comments/comment.html.erb' -->
<%cache comment do%>
  <%= comment.value %>
<%end%>

Rendering the user’s show it will generate a log like:
cache_digest1

The cache key  for users/show is suffixed with an MD5 of the template itself and all its dependencies. If  we change anything in any view(users/show, _blog or _comment) and restart the server, it will automatically expire the cache key and recompute a new cache key.

In production, we don’t need to worry because every time we deploy our application it restarts the server.

Check Dependencies of Template

To check the dependencies of a view, the cache_digests gem provides two rake tasks

1. rake cache_digests:dependencies TEMPLATE=users/show 

I got the following output by running the above task

dependency_task

It gives you the dependencies of the user/show view only.

2. rake cache_digests:nested_dependencies TEMPLATE=users/show  which gives the output

nested_dependencies_task

It gives you the dependencies of the user/show view along with all its nested views .

Others way to call dependencies:

1.  We can call a method in render mentioning  the partial name and collection explicitly. For example:

<%= render @user.last_one_month_blogs%>

So we need to mention partial name and collection here

<%= render :partial => 'blogs/_blogs', :collection => @user.last_one_month_blogs%>

2. If we are using a helper in our render call. Then we need to use a comment that will specify the template dependency

<%# Template Dependency: comments/comment %>
<%= render_comments(blog)%>

Wrap Up

Basically, I wanted to explain caching in Rails and how many ways caching can be accomplished.

More Resources -:

RubyMotion Workflow Customizations

[shared via Google Reader from RubySource]

rmyourway

RubyMotion is a set of tools that simplifies the development of iOS applications, compiling source code to native iOS machine language. It shares its heritage with MacRuby, making it a familiar option for experienced Rubyists to develop applications for iPhone/iPod/iPad.
RubyMotion provides direct access to iOS Classes and Libraries, RubyGems and supports the mixing of Ruby and Objective-C style calling conventions.
The structure of an iOS application observes MVC (like Rails) and RubyMotion’s Command-Line workflow is driven by a Rakefile; just like Rails.

Your standard workflow in RubyMotion will probably include Bundler and RVM { As of this writing, RubyMotion requires a minimum of Ruby 1.9 }

But these similarities to Ruby on Rails are, in many cases, only superficial.

In this article I want to focus on the Rakefile that is used in RubyMotion applications. And I hope to provide some help in keeping your work a bit more organized (and DRY) once you have several RubyMotion applications in development.

The techniques and ideas I present here are my own – carry no particular warranty – and are presented as guidance. You are encouraged to take what is presented here and expand it or adjust it to suit your needs.

If you create something particularly interesting or unique, I hope you share it with the community (in a Gist or repository on Github) and comment to this post.

The RubyMotion Project Structure

To instantiate a new application (project) the command is simply motion create applicationName

This builds the structure of a RubyMotion application like this:

applicationName
    \
      Rakefile
    \
     resources
    \ app
         \
          app_delegate.rb
    \
     .gitignore
    \
     spec
         \
          main_spec.rb

If you are familiar with iOS development (perhaps you have worked in Objective-C with XCode), the app\delegate.rb may be recognizable.

  • The resources directory is where all images, icons and other resources should be maintained.
  • The .gitignore has many sensible defaults already defined for you. Although you will still need to git init a repository for your project.
  • The spec directory is for the tests (you ARE writing tests for your Ruby, are you not?). RubyMotion uses Bacon (an RSpec clone). And a sample spec is created by default.This build system that generates these files is Open Source on Github at HipByte/RubyMotion.The part of this system that will be the focus of this article is the Rakefile.

The RubyMotion Rakefile is the “Heart and Soul” of your CLI workflow. Very much like Rails, most tasks you need are just a rake command away. You can create customized tasks by editing it and get a list of current tasks with a call to rake -T.

Here is the list of rake commands for RubyMotion 1.32

rake archive               # Create an .ipa archive
rake archive:distribution  # Create an .ipa archive for distribution (AppStore)
rake build                 # Build everything
rake build:device          # Build the device version
rake build:simulator       # Build the simulator version
rake clean                 # Clear build objects
rake config                # Show project config
rake ctags                 # Generate ctags
rake default               # Build the project, then run the simulator
rake device                # Deploy on the device
rake simulator             # Run the simulator
rake spec                  # Same as 'spec:simulator'
rake spec:device           # Run the test/spec suite on the device
rake spec:simulator        # Run the test/spec suite on the simulator
rake static                # Create a .a static library

Rake Holds Configuration Details

Unlike Rails, where you rarely need to modify the Rakefile unless you are developing customized commands, in RubyMotion much of the configuration details that are specific to your application will be in this file. In other words, each application in RubyMotion will have its own – unique – version of the Rakefile.

Most libraries and gems that you wish to require (due to the static compilation, RubyMotion cannot support ‘include’) will be referenced in the Rakefile. The specific icons used in your application and the Codesign credentials must be added to the Rakefile.

Also, any credentials for APIs you may be using are read from the Rakefile.

{You can always check on the current configuration with the commmand rake config (see above)}

The Dilema

I have always been quite hesitant to include the Rakefile in my Git repository; particularly on projects I may offer publicly. But since it is an essential part of the whole process it cannot simply be excluded.

How to obscure any ‘proprietary’ credentials while providing the necessary configuration details has been a point of much discussion in the RubyMotion community. One obvious solution (and a very popular one) is to define “environment variables” for those sensitive pieces of data.

Although that works well, I want more flexibility and prefer something less tightly coupled to any particular device (I work on multiple computers).

My Solution

In my RubyMotion workflow I have chosen to define the Rakefile as a symbolic link in every project. My Rakefile symlink points to a single Rakefile that lives in a parent directory. This is a very DRY approach to managing the Rakefile, all “proprietary” credentials, and any customization (as far as additional Rake Tasks). In order to provide the necessary flexibility, I have modified that base Rakefile to load from a app\_properties.rb that lives in every application’s home directory.

Here is an example of a generic Rakefile. This assumes the Rakefile exists just one level up from any RubyMotion project. {This file has been anonymized for publication}

#-*- coding: utf-8 -*-
$:.unshift("/Library/RubyMotion/lib")
require 'motion/project'
# custom rake tasks can go here
desc "Open latest crash log"
task :log do
  app = Motion::Project::App.config
  exec "less '#{Dir[File.join(ENV['HOME'], "/Library/Logs/DiagnosticReports/#{app.name}*")].last}'"
end
require './app_properties'  #this is the call to a file that exists in every project
props = AppProperties.new
props.requires.each { |r| require r } if props.requires.size > 0
Motion::Project::App.setup do |app|
  app.name = props.name
  app.identifier = props.identifier
  app.delegate_class = props.delegate
  app.version = props.version.scan(/\d+/).flatten.first
  app.short_version = props.version.scan(/\d+/).first #required to be incremented for AppStore (http://bit.ly/ZmWpuT)
  app.icons = props.icons
  app.device_family = props.devices
  app.interface_orientations = props.orientations
  app.provisioning_profile = props.provisioning
  app.codesign_certificate = props.developer_certificate
  if props.testflight?
        require 'motion-testflight'
    app.testflight.sdk = 'vendor/TestFlight'
    app.testflight.api_token = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
    app.testflight.team_token = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
    app.testflight.distribution_lists = ['Developers', 'Testers']
  end
  if props.pixate?
      require 'rubygems'
      require 'motion-pixate'
    app.pixate.user = 'USER ID'
    app.pixate.key  = 'XXXX-XXXX-XXXX-XXXX-XXXX-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX-XXXX-XX'
    app.pixate.framework = 'vendor/PXEngine.framework'
  end
end

And a sample of the app_properties.rb file that would be in the root of every RubyMotion project.

class AppProperties
  VERSION = '0.9'
  APP_DELEGATE = 'AppDelegate' #default
  COMPANY_NAME = 'com.websembly.'
  def name
     'App Name Here'
  end
  def version
   VERSION
  end
  def requires  #add libraries to listed in Rakefile as 'require'
    ["sugarcube"]
  end
  def frameworks
    []
  end
  def contributors
    ["Thom Parkin" => "http://bit.ly/16Er5fq"]
  end
  def developer_certificate
    'iPhone Developer: Thom Parkin (1337THX1138)'
  end
  def provisioning
    './provisioning' #symlink
  end
  def testflight?
    false
  end
  def pixate?
    true
  end
  def delegate
    APP_DELEGATE
  end
  def icons
    icn = ["#{self.name}.png", "#{self.name}-72.png", "#{self.name}@2x.png"]
  end
  def devices
    [:iphone, :ipad]
  end
  def orientations
    [:portrait, :landscape_left, :landscape_right] #:portrait_upside_down
  end
  def identifier
    COMPANY_NAME + APP_DELEGATE
  end
end

You may notice that the provisioning profile is also a symlink.


And so, in each of my RubyMotion projects the Rakefile that is generated by the RubyMotion create command gets replaced by a personalized app_properties.rb file that contains the generic instructions plus those things unique to that application (like the application name).

The flexibiliy and value of this continues to grow as I expand my use of libraries and additional helpers in my RubyMotion workflow. For example, I recently started using Pixate in my RubyMotion projects. In order to add this capability to all my RubyMotion projects, I simply updated the master Rakefile and can include the necessary references in each app_properties.rb file where it applies.

As I said before, this is ONE WAY to accomplish this effect. It may not be the best way and I invite you to enhance it. If you do, please let me know.

Painless restart to windows with Alfred/Shell script

Update: a new version of this workflow is available here

I hardly ever shutdown or even restart my mac. Do you dislike all the hassle of restarting your Mac and holding down alt key, etc?

It’s time to end this with a shell script. before we jump into that, we need to do a few things. good thing is it does not change your startup disk. if you restart from windows, your mac will boot into OSX. Brilliant!

Read More

bjk5

Breaking down Amazon’s mega dropdown

bjk5:

The hover effects on Amazon’s big ‘ole “Shop by Department” mega dropdown are super fast. Look’it how quick each submenu fills in as your mouse moves down the list:

image

It’s instant. I got nerd sniped by this. Most dropdown menus have to include a bit of a delay when activating submenus. Here’s an old Khan Academy dropdown as an example:

image

See the delay? You need that, because otherwise when you try to move your mouse from the main menu to the submenu, the submenu will disappear out from under you like some sort of sick, unwinnable game of whack-a-mole. Enjoy this example from bootstrap’s dropdown menus:

image
I love bootstrap, don’t get it twisted. Just a good example of submenu frustration.


How did Amazon get away without using a delay?


It’s easy to move the cursor from Amazon’s main dropdown to its submenus. You won’t run into the bootstrap bug. They get away with this by detecting the direction of the cursor’s path.

image
If the cursor moves into the blue triangle the currently displayed submenu will stay open for just a bit longer.

At every position of the cursor you can picture a triangle between the current mouse position and the upper and lower right corners of the dropdown menu. If the next mouse position is within that triangle, the user is probably moving their cursor into the currently displayed submenu. Amazon uses this for a nice effect. As long as the cursor stays within that blue triangle the current submenu will stay open. It doesn’t matter if the cursor hovers over “Appstore for Android” momentarily — the user is probably heading toward “Learn more about Cloud Drive.”

And if the cursor goes outside of the blue triangle, they instantly switch the submenu, giving it a really responsive feel.

So if you’re as geeky as me and think something this trivial is cool, I made a jQuery plugin that fires events when detecting this sort of directional menu aiming: jQuery-menu-aim. We’re using it in the new Khan Academy “Learn” menu:

image

I think it feels snappy. I’m not ashamed to copy Amazon. I’m sure this problem was solved years and years ago, forgotten, rediscovered, solved again, forgotten, rediscovered, solved again.

If anyone else on the planet ends up finding a use for jQuery-menu-aim, I’d be grateful to know what you think.



Thanks go to Ben Alpert for helping me understand the linear algebra / cross-product magic Amazon uses to detect movement inside the “blue triangle.” I ended up going w/ a cruder slope-based approach, mostly b/c I’ve lost all intuitive understanding of linear algebra. Sad. Need to watch more KA videos.