Code by Design @mittsh-blog - Tumblr Blog

Paw: Let me restore the interface

Many of you asked to implement State Restoration, a way to restore the UI state after the app is closed. After investigations, Paw actually works correctly, the problem many of you (including me) probably have is in the System Preferences. In the General section, uncheck: "Close windows when quitting an application", and it will do the trick.

Though, there is still a bug, that will be fixed in 2.0.6: the state of the Request List is not correctly saved when using groups (Collapsed or expanded state is not preserved).

#paw http client

Paw: Crash on OS X 10.7 Lion (Paw <= 2.0.5)

Someone just reported me a crash on Paw when running OS X 10.7 Lion. It's because of the use of an API not available on Lion :(

The crash report looks like:

Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSFileManager trashItemAtURL:resultingItemURL:error:]: unrecognized selector sent to instance'

It will be fixed for sure in the next release (2.0.6). Though, there is a workaround. In your Terminal run:

rm ~/Library/Containers/com.luckymarmot.Paw/Data/Library/Application\ Support/Responses.sqlite

And it should fix the issue.

#paw http client

Paw: How to get started with Paw2

#paw http client

Paw: How to use Response Parsed Body Dynamic Value

So I'll continue to write some tips about Paw, to temporarily compensate the lack of documentation...

Dynamic Values are quite helpful to make your requests flexible, avoid constant copy/paste, make your computations right in the app, etc. It's adding some magic to HTTP testing.

The Response Parsed Body Dynamic Value parses JSON, XML and URL Encoded (Content-Type application/x-www-form-urlencoded) responses so you can send back some field in another request.

Copy right from the response (JSON and URL Encoded)

When you have a JSON or URL Encoded response, you can copy all set up the Dynamic Value right from Response View. Just right-click on an element, and the option Copy as Dynamic Value will show up.

Once done, the Dynamic Value is in your clipboard, ready to be pasted anywhere.

As you can notice here, the Dynamic Value takes the value from the JSON of the previous request.

Create in a field

As Response parsing is not (yet) supported for XML, you can't copy from the response in that case.

In any field, right-click and pick Response > Response Parsed Body.

Then choose the request you want to parse, and optionally the format (in Automatic mode, the format will depend on the response Content-Type header). The Key Path is the path to the element you want to access. The path is composed of keys separated by dots ., or indexes [i] for arrays and lists.

For JSON, you may have something like items[0].name

For XML, the access item.attribute for attributes, and item.text for its value. It's somehow similar to XPath

For URL Encoded, just specify the key you want to access

#paw http client

Paw: How to use Environment Variables?

Since the release of Paw 2 in November, I see a lot more of excitement from users, which is an amazing feeling as a developer. There was many bugs to fix in the early versions of Paw 2, so most of the support emails I received where bug reports. Now, it's different, few bugs, more feature requests and also simply questions. It's greatly time for me to start to write some doc! In the meantime, I'll try to post some tips...

Environments let you have some variables that can take different values. An environment is a set of values that the variables can take. For example, your variables would be Port, Host and Protocol, and you would have different values for them for your 2 environments Development and Production.

Create and Edit Environments

The Environment drop down menu is just over the Request List. Hit the button, and Add new environment. Let's call it Development.

Now we can switch to our other environment, and rename it to Production. And assign values to our variables.

Hit OK, and come back to the request.

Use Environment Variables in your requests

In the URL field (or generally, any field), right-click, and you'll find your variables in the context menu under Environment > Environment Variable. Just choose the variable, to insert it in the field.

Now, you can build very flexible requests :)

One more thing, use the Code Inspector (Cmd+Shift+Y to show/hide) and pick HTTP to preview how the request has been generated.

Bug notice: when switching between environments, the code generation is not refreshed, so change one character in your request to trigger the update. This will be fixed in the upcoming version 2.0.6.

#paw http client

42sh/mmalloc: How to make your C program never ever leak

42sh is a bash-style shell we developed at school in C. It was a 4 weeks project, with 5 team members, even though all were not as fervent we, JC and I, were. EPITA is one of the leading Computer Science Engineering School in France, and make us learn low-level stuff (including some asm) to allow us understand deeply what's going on under the hood.

No memory leaks. At all.

The boldest instruction was: "If you leak, you're dead, even for one leak". Valgrind was their witness. We hacked night and day to make our shell work, from old-style dirty parsing (Bison, Flex, Lex, Yacc, even Regex libraries were forbidden), to AST building and interpreting. Though, the last weekend, we had 2 leaks left, in the very edge case where the user would quit badly the shell. And we weren't sure whether we missed some other cases, and would loose pride with even one nasty leak.

So JC and I decided to write mmalloc (yes, malloc with 2 m, like mittsh-malloc). It also had mfree, mcalloc and mrealloc, and worked exactly as the original library functions. Except something. It kept a linked-list of pointers to all allocations. So when in need, we just had to call mmalloc_free, the magic function we documented as Frees all the managed heap.. We added some calls to signal, and catching all including SIGTERM, to free the heap even if we crash!

In fact, the day of presentation, the jury asked us dubiously So, is there any leak?, JC answered very convinced No leak. The dude insisted Are you - really - sure?. We confirmed. After running their Valgrind-based test suite, they had to admit: Nice, you're the first team today saying No Leak, and actually not having any.. That was our humble way to beat the system.

See mmalloc here.

#epita #valgrind #bash #shell #42 #malloc #memory management

Paw 2: Available this week

That was a long way to go! Paw 1 was released on the Mac AppStore almost 8 months ago, on March 15, 2013, and since then it only got positive reviews. I received tons of features requests from excited users who wanted to see Paw being improved to fit even better their needs.

The less positive review Paw got was complaining a little bit about the limited number of features. No doubt it was limited. I wanted to keep it simple: edit an HTTP request, send it, and see the result. Nothing more. It was just about adding a nice GUI on cURL. But doing it well was already a big chunk of work. If it made developers save 15 min of time each day, it was sold. I needed to find where are the biggest pains, and fix them. Simply adding a great text completion, the ability to save and version the tests on GIT, coloring JSON responses, and exporting to cURL was a good start for Paw.

Mac AppStore Screenshot for Paw 1

It was finally doing well, and I see the number quite as a success for me. Paw reached the top 10 grossing Developer Tools in 36 countries, and was even first in 14 countries, including China, Hong Kong and South Korea. The US market is more competitive, but it reached #26 on March 18, 3 days after being released.

Now, time for Paw 2

Paw 2 was available as a beta, featuring most of the features that has the final.

Oh, one more thing, Paw 2 has a whole new design. Beta versions had almost voluntarily a very nerdy look because I want to keep a surprise for you :)

#paw http client

Cocoa: Please never draw your NSView, NSCell and CALayer using -[NSScreen backingScaleFactor]

This is so wrong! And I saw it in many StackOverflow answers.

I have a Retina Mac which is almost always plugged to an external non-retina 22” monitor: some windows are drawn as retina and some are not. And it matters. The shortcut I’ve seen too often is [[NSScreen mainScreen] backingScaleFactor]. My main screen is the built-in retina one so this call will always return 2.0f ; then what about the windows on the external non-retina display? They will be drawn for a retina display, and then uglily scaled down by the system.

Why people are getting confused with NSScreen?

This back practice is probably inherited from iOS, where everyone’s dealing with the UIScreen. Well, this is wrong on iOS too, since an iOS device can have multiple screens and windows. Think about AirPlay.

The right answer

It's so simple. If you are drawing in your NSView or NSCell code, just call -[[myView window] backingScaleFactor]. In the case the window is moved across screens, all will be redrawn with the new backing scale factor. Though, it’s a little trickier if you’re using a CALayer. In your -[CALayer drawInContext:] method, get [self contentSize]. This part is easy, but the view backed by the CALayer needs to keep the layer updated by any change of the scale factor:

- (void)viewDidChangeBackingProperties { [super viewDidChangeBackingProperties]; [[self layer] setContentsScale:[[self window] backingScaleFactor]]; }

Hope it helps! And please give me a favor, forget about -[NSScreen backingScaleFactor].

#Cocoa #ios #nsview #backingscalefactor #retina

Spotify is smart at increasing the Cost-per-view of its audio ads

You too? You thought you're smarter than the machine when you mute the volume during ads? Then it's over! Spotify beats you. When you mute, or reduce the volume below a given level, it pauses the ad, so it can resume when you're ready to listen! Awesome way to increase the CPV, Spotify! Well done!

#spotify #advertising

Startup Classes

As we are working on Orangery, we attend to some classes about startups. Here are some notes:

The Art of Going Global by Bill Reichert, Garage Tech Ventures

Getting to Wow by Bill Reichert, Garage Tech Ventures

Coming to the US to do business by Todd Rumberger, Foley

Still an excellent guide to how to pitch for your startup is the Guide to YC by Jason Shen, cofounder of a YC-funded startup: Ridejoy.

The future of testing REST services/APIs – Paw HTTP Client 2.0 Beta 2

That's now over 6 months I released the first version of Paw HTTP Client on the Mac AppStore!

I was trying to solve the lack of tools developers have on their hands to play with REST services. You may know the Chrome Apps REST Console or Postman, there are also a plenty of small basic apps on the MAS. But none of them were convincing me, mostly because I couldn't save, organize and commit my tests on GIT to share with the team – not to mention the UI and usability issues. I wanted to build a native Mac app, with a nice frictionless UI to send HTTP requests and see how they are doing. So far, I got many very positive reviews and dozens of kind emails with very relevant feature requests and suggestions.

But since then, I see a bigger problem. It's not anymore just a matter of writing static HTTP requests and see how the server responds, it's also sending dynamically computed content, often depending on the context – like OAuth relays on timestamps and nonces – or hard/bothering to manually create (like files hashes for S3, or values extracted from previous server responses). And why not in the future say what you expect the server to return – HTTP Status Code, or some value inside a JSON – to create your unit tests.

Last month I sent to a small number of users the first beta of what will become Paw HTTP Client v2.0. Now the beta 2 is ready, mostly bringing bug fixes and a few new features some requested by users. Still the design is far away from the nice polished skin I want to give it, and it still lacks at least a big feature I'm planning to add. But I think it's time to ask for more feedback on what I'm doing.

You can download it here: http://bit.ly/paw2beta2. It's a Developer ID signed + sandbox app, so you're safe :)

#rest api #paw http client

Cocoa/OS X: Debug Key View Loop

Quick Answer

Get this gist: https://gist.github.com/mittsh/6668638 And use LMWindow instead of NSWindow in IB or anywhere you are creating your window. It will add 2 menu items in your app menu, with keyboard shortcuts: Cmd + O to show an overlay on the first responder and Cmd + P to dump your key view loop in the console.

The Whole Story

Find me one Cocoa developer who never had any problem with the key view loop. Just one. Yet, after Googling and reading a lot of Stack Overflow threads I can't find any good way to debug my key view loop for Paw 2.

The first advise that comes everywhere is to toggle the Full Keyboard Access setting in System Preferences > Keyboard. But in most cases it doesn't help much: NSScrollView, NSClipView, NSMatrix (and many more) are in the key view loop and are mostly invisible because sometimes they pass the first responder status to a child view, plus they don't have a focus ring to make them visible. So I came up with a quick-and-dirty debug solution (see end to get the code):

Yes! It simply highlights the current responder using a child window. You can toggle this highlight using Cmd + O, since it actually adds 2 menu items in the app menu:

And to make deep, console-based debug Cmd + P will help:

Here's who to decode that logs:

When a line is starting with > the responder accepts to be first responder (aka. -acceptsFirstResponder returns YES), it shows - in the other case.

As you guessed, the first column shows the class of that responder

Indents in this column represents the view hierarchy, often the next key view is a descendent view. Note that an indent doesn't necessarily means that a view is a subview of the previous one, it means any descendent (subview of subview...).

The second column shows the identifier you may have set on IB

Again, you guessed it, the memory address (useful to access it from the debugger).

As promised, here's the gist with the full code: https://gist.github.com/mittsh/6668638 Simply create the LMWindow class, and use it for as your window (or make your custom window subclass inherit from this one).

#cocoa #osx #key view loop #nextKeyView

Ember.js: How to use static arguments in a bound helper

Background

One of the cool things with Ember.js are Helpers since they gives you a wildcard for flexibility in your Handlebars templates. It's somehow equivalent to Django's Tags (eventually filters).

Ember.Handlebars.registerHelper 'capitalize', (value) -> value.toUpperCase()

And simply call:

This looks great until you need to need to update the value of the helper when its input changes. Ember invented bound helpers, same behavior except that it binds all arguments, so if one changes, the result is recalculated. Use registerBoundHelper instead of registerHelper:

Ember.Handlebars.registerBoundHelper 'capitalize', (value) -> value.toUpperCase()

Let's say you want to generate a Google Maps URL for a given location, you'd expect to simply call your helper:

And that works fine. But then you want to pass the size (a static number) of the map you wanna get:

It doesn't work anymore. Handlebars recognizes 500 and 400 as variable names, and therefore evaluates their value to undefined. Try also quoting these values, it does the same: "500" or '500'.

Problem: How to use static argument in a bound helper?

In one word: use options.

They are passed as the last argument:

Ember.Handlebars.registerBoundHelper 'googlemaps', (latitude, longitude, options) -> return "http://maps.googleapis.com/maps/api/staticmap?" + "center=#{latitude},#{longitude}&" + "zoom=#{options.hash['zoom'] or 13}&" + "size=#{options.hash['width']}x#{options.hash['height']}&" + "scale=2"

I'm always using CoffeeScript for the JavaScript snippets simply because I like the syntax better and think it's easier to read.

#Ember.js #handlebars

Ember.js: An easy and clean way to set the page title

I started to learn and start a fresh new project using Ember.js a few weeks ago, and so far it answers all my needs with a lot of elegance.

The only unsolved question I had was how to set the page title <title> in a clean way, and there are no real answers so far. A very nice solution has been introduced on a still open pull request: Router now observes the 'title' property on route handlers and sets document.title. But since I don't want to branch out of the current released code, I opted for my quick homemade solution, while keeping a design that will be compatible when this pull request will be merged to the next release.

I created my own AppRoute subclass:

AppRoute = Ember.Route.extend renderTemplate: (controller, model) -> this.render() pageTitle = if this.title then this.title controller, model else null document.title = if pageTitle then "#{pageTitle} – My Website" else "My Website" return

And make every other route extend this one, like:

App.IndexRoute = AppRoute.extend model: () -> return App.Page.find()

And some of them will implement the title function:

App.PageRoute = AppRoute.extend model: (params) -> return App.Page.find params.page_id title: (controller, model) -> return controller.get('title')

I published a gist to show to complete solution, including a heading containing the same title: Ember.js: Easy setup to set document title + having a heading view containing the same title using a subclass of Ember.Route.

#ember.js

Trending Blogs

Recently Viewed Blogs

Code by Design