Happy New Year everyone! A small bug fix release for Charles, tidying up two bugs that were discovered in the 3.5 release. These include a fault in the Repeat Advanced tool, where it would fail after a number of requests, and a fault in the Auto Save tool where it wouldn’t save the “Enable on startup” setting.
Charles v3.5 is now available, just in time for Christmas. It contains a number of significant new features, enhancements and bug fixes. They’re all detailed on the version history page.
The UI has been improved again and is now looking sensible on Windows 7 (thanks to an update from JGoodies) and better on Mac OS X (thanks to Quaqua, and some work getting rid of duplicate borders). It’s a hard road making Charles look sensible across all of these different platforms, but I hope that the direction is always up!
Users with Microsoft proxies or proxies that require NTLM authentication; you’re in luck! I’ve implemented NTLM authentication into Charles using the JCIFS library, so you can now enter your Domain, Username and Password in the External Proxy Settings dialog and never be bothered by proxy authentication again. Various other external proxy related fixes are also in this release so it should be a good one for you guys.
Users who dare to venture into WireShark or TCP Dump… I too have had to go there, particularly to debug a performance issue in Charles, so I’ve added PCAP import to Charles. It’s a little basic at the moment so I expect there to be PCAPs that don’t import correctly – if you can, please send them to me so I can increase my test coverage and fix up faults! PCAP import is HTTP only, it can’t import HTTPS (of course).
Transparent proxying is now an option on the HTTP proxy configuration in the Proxy Settings. This is mostly useful if you’re a network guy and can configure your firewall to route traffic through Charles. This can help you capture traffic from more stubborn applications.
As always, contact me via the form on the Charles website if you encounter any bugs. Otherwise, best wishes for Christmas and New Year. See you in 2010!
This is a minor feature and bug fix release. Firstly, it fixes the regression bug in v3.4 that broke request body editing in Breakpoints. Thanks to everyone that reported and tested that for me – your help is most appreciated. Secondly, it replaces the functionality that you could paste a full URL into the Location form. It works even better now, as you’ll see, and there are warnings if you enter inappropriate things in different fields to make it more likely that you’ll get the right result!
After six months of development I’ve released Charles v3.4.
This version features major SSL changes improvements including:
Version 3.4 also adds a much requested “only record these sites” option in the Recording settings. I am still working on a better way to reduce the noise in Charles, but this will be useful in the meantime.
There are many other changes and fixes listed in the Version History, please take a look.
Please let me know if you encounter any problems, particularly regressions.
Charles v3.4 is in the works. I haven’t settled on a final feature list for this yet; my focus is intended to be UI improvements, but I couldn’t resist releasing some new SSL features. So this isn’t really a beta, but I’m calling it 3.4b1.
Charles now supports client-side SSL certificates, so you can authenticate with servers that require them. You must configure Charles to use your P12 file for each site that requires it using the Client SSL Certificates option in the Proxy menu. Charles will ask for your password when it needs it, and it doesn’t remember it beyond the session for your security. Please let me know how this works for you!
You can now list SSL sites that should not be proxied / decrypted by Charles. In the process I also renamed “Decrypt SSL” to “SSL Proxying” as it wasn’t the right terminology. So if you have software that accesses specific sites and doesn’t like Charles’s certificates you can add them here; by default it has PayPal and Kagi in there to ward off the emails I get about those sites having invalid certificates! For myself I’ve added *.getdropbox.com as it doesn’t like the SSL certificates it sees even with Charles’s CA certificate trusted by the system – that’s good security.
Finally, the SSL certificates that Charles generates for sites are now cached. This means when you say “permanently trust this certificate” in your browser, it will actually work!
Several years ago I wrote this RomanNumeralFormat class which extends java.text.NumberFormat but parses and formats Roman numerals. I just stumbled across it and thought it belonged here. This sort of thing should definitely be included in Java 7, then it will truly rule over Perl 6.
import java.text.FieldPosition;
import java.text.NumberFormat;
import java.text.ParseException;
import java.text.ParsePosition;
public class RomanNumeralFormat extends NumberFormat {
private static char[] roman_alpha = new char[] { 'M', 'D', 'C',
'L', 'X', 'V', 'I' };
private static int[] roman_num = new int[] { 1000, 500, 100, 50,
10, 5, 1 };
public StringBuffer format(double number, StringBuffer toAppendTo,
FieldPosition pos) {
// Too lazy
return null;
}
public StringBuffer format(long l, StringBuffer toAppendTo,
FieldPosition pos) {
StringBuffer buf = new StringBuffer(20);
while (l > 0) {
for (int i = 0; i < roman_num.length; i++) {
if (l >= roman_num[i]) {
buf.append(roman_alpha[i]);
l -= roman_num[i];
break;
} else {
int peek = i + 2 - (i % 2);
if (peek < roman_num.length) {
int j = roman_num[i] - roman_num[peek];
if (l >= j && j > 0) {
buf.append(roman_alpha[peek]);
buf.append(roman_alpha[i]);
l -= j;
break;
}
}
}
}
}
return buf;
}
public Number parse(String source, ParsePosition parsePosition) {
long l = 0;
int max = 0;
source = source.toUpperCase();
for (int i = source.length() - 1; i >= 0; i--) {
char c = source.charAt(i);
boolean validChar = false;
for (int j = 0; j < roman_alpha.length; j++) {
if (roman_alpha[j] == c) {
int k = roman_num[j];
if (k >= max) {
l += k;
max = k;
} else {
l -= k;
}
validChar = true;
break;
}
}
if (!validChar) {
parsePosition.setErrorIndex(i);
return null;
}
}
parsePosition.setIndex(source.length());
return new Long(l);
}
}
I was obviously pretty concerned about getting some large roman numerals through here – using a long rather than an int. Built to last.
Half a year on from the launch of the iTunes App Store, one of the biggest difficulties for developers is getting noticed amongst the 10,000+ apps. We’ve talked about traditional marketing; we’re trying new forms of marketing (twitter, social networking), but mostly agree that promotion within the App Store itself is the golden ticket. I’ve had this idea rolling around for some time; today I’m appeasing my Things todo list by blogging about it.
Promotion within the App Store is available in two areas; the masses purchase apps creating the Top 10 / 25 / 50 / 100 lists, and Apple chooses apps to feature in the New and What’s Hot lists (and some others). Promotion within the App Store is at the whim of Apple and the masses.
The problems with the Top lists has been the topic of much discussion; most recently its penchant for passing wind has been fouling the air. The Top lists create a feedback loop where sales drive sales; it’s great when an app is in the loop, but increasingly developers are finding development unsustainable if it’s not.
My assumption is that there are many apps of quality and utility that deserve to hit the big time, and that without promotion their growth is stunted. Apple can’t promote every app at once, but maybe the promotion can work better.
I am thinking of a system where potentially successful apps are identified in a way that is independent of sales volume and recommendations. Apps are then randomly promoted with a weighting towards those that are more potentially successful. A feedback loop analyses the effect of promotion on sales and increases or decreases promotion to maximise revenue. In this case “success” is defined as sales, that is making money for Apple and for the developers.
How to identify potentially successful apps? If Apple tracks which apps people view and and which apps they buy, then an app with a strong view-buy ratio likely matches consumer needs and has reasonable quality (bonus points for including data on how long the app stays installed; if the user removes it immediately with a 1 star review that counts against). Identifying apps in this way is independent of popularity; in fact popularity will worsen the view-buy ratio as it attracts more views, so this (and a minimum number of views on the other end of the scale) may need to be taken into account. The potential to tailor featured apps to individual users is obvious, but I think one-step-at-a-time is more likely!
Potentially successful apps are then randomly featured on the App Store with a weighting towards apps with a high view-buy ratio. Being featured will increase the number of views, so if an app is successful it should also increase the sales. The feedback loop continually measures the view-buy ratio and adjusts the promotion weighting. Variance in the weighting algorithm would enhance the approach by stepping back slightly from maximising revenue (ie. for Apple) and sharing it amongst a larger group of apps (ie. developers), and allowing new entrants; like mutation in a genetic algorithm.
I think this approach may solve the problem of apps which should have more sales but don’t have the promotion required. It should mean that promoted apps are the apps that are more likely to sell, which means that overall App Store revenue should increase. Good for Apple, good for developers. Remember that this doesn’t replace the existing Top list mechanism, it sits alongside it. I’m not sure what other problems and exploits it creates! It isn’t a complete picture. I hope it’s an interesting one.
I’ve released Charles v3.3 today. This release adds several new and exciting features including:
I’ve blogged previously about these, and other new features, so I’m just going to link through to those! Read the first announcement and the second announcement.
The next release of Charles will focus on improving various UI and usability features. Particularly the ability to focus in on a small set of hosts, so you don’t get cluttered with others. Also I’ll be making improvements to the Sequence view; probably some sorting. I’ve received lots of suggestions along these lines; if you have anything to add please leave a comment with your thoughts!
We just tracked down an issue where H.264 video would play on the iPhone over WiFi but not over 3G. The problem turned out to be that the server emitted a Vary: User-Agent header as part of its mod_deflate handling. That header alone was causing the video to fail to play over 3G. I suspect that it may have been a problem on the 3G network itself rather than the iPhone. If you have similar head-scratching issues maybe this is the cause.
The second public beta of Charles has just been released. This update adds:
It also includes fixes and improvements to JSON and JSON P and validation. In particular you can now repeat a request within the validation results and have it repeat the original request and then validate the result – really handy for iterative testing and fixing!
This release is heading for final this week I hope so please send your feedback.