Showing posts with label hacking. Show all posts
Showing posts with label hacking. Show all posts

Wednesday, January 13, 2010

Java Developers Guide to Objective-C on the iPhone

This will be a place-holder page containing links to the other entries that I create in this series. I've got a lot of commercial experience with Java, some Python and Ruby. This has all been server-side; I've not really touched GUIs (apart from GWT, HTML and Javascript) for a while, so this series will necessarily reflect that. Hopefully it will prove useful to others.

Topics that I hope to cover:

Wednesday, November 11, 2009

Google Gears for Firefox 3.5 on Ubuntu Karmic 9.10

Built my own - seems to work fine so far.


jabley@miq-jabley:~/work/gears-read-only$ svn info
Path: .
URL: http://gears.googlecode.com/svn/trunk
Repository Root: http://gears.googlecode.com/svn
Repository UUID: fe895e04-df30-0410-9975-d76d301b4276
Revision: 3410
Node Kind: directory
Schedule: normal
Last Changed Author: gears.daemon
Last Changed Rev: 3410
Last Changed Date: 2009-11-10 01:49:08 +0000 (Tue, 10 Nov 2009)


Made some changes:



make mode=OPT

and then install the resulting xpi.

Friday, October 23, 2009

Monday, March 30, 2009

Java doesNotUnderstand-like behaviour in Eclipse

Kent Beck tweeted this recently. I've been doing this for years, but I guess it's not as widely used as I assumed.

Window | Preferences | Java | Code Style | Code Templates | Code | Method Body


// ${todo} Auto-generated method stub
throw new UnsupportedOperationException("Not implemented");


Then add a breakpoint to your Debugger Breakpoint view:

New Java Exception for UnsupportedOperationException that hasn't been caught.

IDEA supports something similar, since I had it set up then as well, but I've not used IDEA for a couple of years.

I tend not to use debuggers; I prefer tests, but sometimes a debugger's the thing.

Sunday, February 01, 2009

Java REPL

Obviously, most good dynamic languages for the JVM have this, but still, it's sweet.


$ jirb
irb(main):001:0> require 'lib/org.restlet.jar'
=> true
irb(main):002:0> http = Java::OrgRestletData::Protocol::HTTP
=> #<Java::OrgRestletData::Protocol:0x59cbda @java_object=#>
irb(main):003:0> client = Java::OrgRestlet::Client.new http
=> #<Java::OrgRestlet::Client:0x800aa1 @java_object=#>
irb(main):004:0> r = client.get 'http://www.apache.org/'
01-Feb-2009 22:54:08 org.restlet.engine.http.StreamClientHelper start
INFO: Starting the HTTP client
=> #<Java::OrgRestletData::Response:0x12a416a @java_object=#>

Monday, January 26, 2009

JAXP pipelines using SAX

XProc looks handy, but is not in a usable state yet. So I had to roll my own pipeline as a one-off recently, and seemed to struggle more than I expected. The requirement was fairly simple

  1. Ingest some HTML and convert to well-formed XML for processing;

  2. filter that XML to remove unwanted content;

  3. convert the XML to a different format.


Step 2 was a new bit - I already had well-tested code for the other two parts. So I wanted to re-use that as much as possible. JAXP pipelines using SAX looked to be (and is!) very nice for this, but examples seemed a bit thin on the ground. I've put a version of it here, in the hope that others may find it useful.

/* Create an InputSource for the pipeline input document. */
InputSource in = new InputSource(new ByteArrayInputStream(StringUtils.getBytes(text, "utf-8")));

/* Step 1. TagSoup parsing to get well-formed XML */
XMLReader reader = new Parser();

try {
SAXTransformerFactory stf = (SAXTransformerFactory) SAXTransformerFactory.newInstance();

StringWriter sb = new StringWriter();

OutputFormat outputFormat = new OutputFormat();
outputFormat.setOmitXMLDeclaration(true);

XMLSerializer serializer = new org.apache.xml.serialize.XMLSerializer(outputFormat);
serializer.setOutputCharStream(sb);

/* Step 2. Remove unwanted markup from the well-formed XML. */
InputStream stripContent = getResourceAsStream("strip-content.xslt");
XMLFilter removeUnwanted = stf.newXMLFilter(new StreamSource(stripContent));

/* Step 3. Convert to preferred markup format. */
InputStream xsltResourceInputStream = getResourceAsStream("xhtml2dial.xslt");
XMLFilter xhtml2dial = stf.newXMLFilter(new StreamSource(xsltResourceInputStream));

removeUnwanted.setParent(reader);
xhtml2dial.setParent(removeUnwanted);
xhtml2dial.setContentHandler(serializer.asContentHandler());

reader.parse(in);

return sb.toString();
} catch (TransformerException e) {
throw new ConversionException(e.getMessage(), e);
} catch (IOException e) {
throw new ConversionException(e.getMessage(), e);
} catch (SAXException e) {
throw new ConversionException(e.getMessage(), e);
}

Thursday, December 25, 2008

More learning

I like Mercurial. I'm trying to use it more, to see how it can improve my workflow (and trying to resist the complexity of git for the moment). I'm also trying to do a lot with Scheme, thus scratching my itch of learning about language design generally and a Lisp in a more in-depth fashion.

UPDATE: I've actually restricted access to the bitbucket repository at one of the author's request. Leave a comment here if you want access and I'll see about allowing access on a per-person basis. Allowing access will at the very least depend on good verification of the requestor and posting to the group to allow any instructors to veto access.

Tuesday, September 09, 2008

Java Triple DES example

I had to do this recently, and the examples that I found through Google seemed a little lacking. So a pointer to others:



UPDATE

Changed to use a gist on github. That will probably dilute the search ranking of this post (which is reasonably popular) but gives me nicer formatting!

Tuesday, August 26, 2008

Facebook Mega-Data

Just noticed that Facebook open-sourced a version of their BigTable data store and it's hosted on Google code, written in Java. I'll omit the obvious snickers about Facebook cloning BigTable and then hosting on Google Code.

Thursday, February 07, 2008

Minor casualties from the disk crash

There was some loss - mainly source code for personal hacking. My Jython UnicodeData implementation was lost, although I did have a copy of that in my GMail Sent folder which has been contributed to the committers in the hope that someone with more time and enthusiasm than me finds it useful. Apparently they have. The other thing lost was my WideFinder sketching. I surprisingly did have an early warning that the disk was close to failure, when my implementation (which was clocking ten seconds or something) suddenly started taking twenty minutes to complete. Obviously I didn't pick up on this warning; instead blaming it on some horrible mistake in my code. Some learnings from my WideFinder experience.

  • NIO can be tricky, and should probably have an easier API in comparison to classical IO. It was nice to look at this anyway, and I'll probably have a read of the Jython and JRuby IO stuff to see how others do it, and also the Apache NIO stuff.
  • Java string matching is slow using regexp. I'd not got as far as implementing Boyer-Moore or similar, but I expected to get a big hike out of my 10 second time when switching to that.
  • CAS is good, versus synchronized blocks. Brian Goetz has talked about the advantages of non-blocking forms elsewhere.
  • Java is quite restrictive. I must have been doing too much Common Lisp, Erlang and Scheme recently!

Friday, December 07, 2007

Sunday, November 25, 2007

WideFinder - late entrant

Snagged me a log file and starting cranking out some code tonight. I had some free time to think about this a couple of weeks ago, and got some sketches down, but I've only recently got the data to start seeing how the code can fly. So, I'm starting out on my work Dell laptop, Dual Core Pentium 2GHz with 2GB RAM and a really shitty disk, judging by the slowness and noises it makes (or is that just Vista?) [stay on topic! - Ed]. The Ruby version runs in just over a minute, once all of the caches are warmed up. My initial naive Java version runs in 14 seconds (I haven't figured out yet how to run it using time as per *nix environments - Cygwin says it can't find the time command when I pipe zcat output into it).

Now to start implementing my ideas. I have what I think is the shared update of the accumulator as well as I'm going to get it. I'm hypothesising that most of the updates are uncontended and so don't require the full weight of Java's locking capabilities. Now I just need to parallelize the I/O and determine the most efficient matching algorithm, which seems to be Boyer-Moore from reading the Wide-Finder series. That particular algorithm seems to pop up fairly regularly in searching. Might be interesting to see what else is available in that field, but it should be in a library, surely?

Monday, October 08, 2007

Java Mock Objects tip

Discovered while using JMock, but I would imagine it's also good for EasyMock, RMock, ...


checking(new Expectations() {
{
one(httpServletRequest).getParameter("c");
will(returnValue("-2"));

one(httpServletRequest).getParameterNames();

// StringTokenizer implements Enumeration. A bit cheeky!
will(returnValue(new StringTokenizer("c")));
}
});

Thursday, August 02, 2007

Jython UnicodeData hacking in the CDS

Got numeric and decimal working today in between contractions in the Central Delivery Suite at Frimley Park Hospital today. Nearly got categories working as well, except I'm not clear how CPython has implemented unicodedata.category for undefined codepoints.

e.g. Python 2.5 uses Unicode 4.2 for the Unicode database. The integer codepoint 13313(decimal) / 3401 (hex) is not defined within Unicode 4.1.

3400;;Lo;0;L;;;;;N;;;;;
4DB5;;Lo;0;L;;;;;N;;;;;

It isn't defined in Unicode 5.0, which is what I've been using to do the Jython implementation.

3400;;Lo;0;L;;;;;N;;;;;
4DB5;;Lo;0;L;;;;;N;;;;;

So how does CPython define unicodedata.category(unichr(13313)) to be 'Lo'? And it doesn't seem to be just 'Lo' in all cases of undefined items. I'm speculating that it might be falling back to the preceding valid codepoint category. Think I need to post to a CPython list to confirm.

Tuesday, July 31, 2007

Google Reader Bug report - use Atom <id/> elements

I am directly subscribed to Sam Ruby's feed. I recently added Planet Intertwingly as well, which contains Sam's blog. Both feeds are served as application/atom+xml. In Google Reader, duplicate items show up (for Sam, Steve Loughran, and others that overlap from my other subscriptions. I don't want to remove individual subscriptions in case Sam removes them from Planet Intertwingly.

From my readings of the spec a while ago, that was an explicit rationale for having id's associated with each entry. As you would expect, the id's are the same. From Planet Intertwingly:


<entry>
<id>tag:intertwingly.net,2004:2619</id>
<link href="http://intertwingly.net/blog/2007/07/31/Agile-Financial-Publishing" rel="alternate" type="text/html"/>
<link href="http://intertwingly.net/blog/2619.atom" rel="replies" type="text/html"/>
<title>Agile Financial Publishing</title>
...
</entry>

From Intertwingly:


<entry>
<id>tag:intertwingly.net,2004:2619</id>
<link href="2007/07/31/Agile-Financial-Publishing"/>
<link rel="replies" href="2619.atom" thr:count="1" thr:updated="2007-07-31T12:15:28-04:00"/>
<title>Agile Financial Publishing</title>
...
</entry>

Those atom:id element IRIs appear to be the same to me...

Friday, July 20, 2007

Good ETag support requires thinking about it up-front

I posted a comment on this but I thought it worthwhile going a little deeper.

Blogger doesn't support Trackback so I'll just post and link.

My point was not to argue about how little code is required to implement sending an ETag and checking an ETag based on the MD5 hash of your content (that's pretty much a library issue which should level out to be equal over time) but to go a little deeper into ETags.

I've been reading Sam Ruby long enough to have had the benefit of ETags drummed into me. The posts that Bill links to are focused on the network savings aspect of conditional GET. But you can also save server processing power, if you put a little more thought into your application model.

So we come back to the requirements for Java frameworks to support ETags such that it is possible to avoid doing the bulk of the server side processing. Caveat this could well be premature optimization, and is merely me thinking out loud. Struts is the one I'm most familiar with and I think with the struts-chain RequestProcessor, this approach could be used, but anything that works as a chain would do for this (so pure Filters would also work).



public void doFilter(ServletRequest request, ServletResponse response,
FilterChain filterChain) throws IOException, ServletException {

HttpServletRequest httpRequest = (HttpServletRequest) request;

/*
* Do something that works out what is required to render a response
* for this request and generate an ETag based on that. So here we
* have moved away from the approach of generating ETags from MD5
* hashes of the response body.
*/
ETag currentResourceETag = calculateETag(httpRequest);
ETag incomingETag = extractETag(httpRequest);

if (currentResourceETag.equals(incomingETag)) {
response.sendStatus(HttpServletResponse.SC_NOT_MODIFIED);
} else {
filterChain.doFilter(request, response);
response.addHeader("Etag", currentResourceETag.stringValue());
}

}

You would need to be able to obtain the items responsible for determining the ETag value reasonably early in the request processing, before any really expensive operations. Not sure what implications that has for the layers in your application, or if you were using strict MVC how disruptive / worthwhile it would be to try this approach...

Wednesday, July 18, 2007

Jython - UnicodeData mirrored is complete!


from test_support import verify, verbose
import sha

encoding = 'utf-8'

def test_mirrored():

h = sha.sha()

for i in range(65536):
c = unichr(i)
h.update(str(unicodedata.mirrored(c)))
print "%i : %i%c" % (i, unicodedata.mirrored(c), unichr(10)),

# Value returned by Python 2.5, which uses Unicode 4.2
#verify('91cd30c6c81911835dbcbed083f99fc9fc073e4a' == h.hexdigest(),
# h.hexdigest())

# Value returned by current Jython implementation, which uses Unicode 5.0
verify('595795a212ca0ac629d6b2dfb09c703a472adb03' == h.hexdigest(),
h.hexdigest())

# Add next test!

if __name__ == '__main__':
import unicodedata
test_mirrored()


OK, it's only for the BMP, but it's a good start. Supporting supplementary characters (in Java terminology) or the other sixteeen planes would need a more fundamental change to PyUnicode, methinks. Now I need to start adding the other unicodedata methods which should be fairly straightforward. Then I'll have a working implementation to post to the dev list. Maybe end of this month, unless Baby comes and I lose my late night hacking time?

Jython UnicodeData mirroring



for i in range(65536):
c = unichr(i)
print "%i : %i%c" % (i, unicodedata.mirrored(c), unichr(10)) ,



jabley@miq-jabley ~/work/eclipse/workspaces/personal/jython-trunk/jython
$ diff jython-mirrored.txt python-mirrored.txt
10177c10177
< 10176 : 0
---
> 10176 : 1
10180,10183c10180,10183
< 10179 : 0
< 10180 : 0
< 10181 : 0
< 10182 : 0
---
> 10179 : 1
> 10180 : 1
> 10181 : 1
> 10182 : 1
11779,11782c11779,11782
< 11778 : 0
< 11779 : 0
< 11780 : 0
< 11781 : 0
---
> 11778 : 1
> 11779 : 1
> 11780 : 1
> 11781 : 1
11786,11787c11786,11787
< 11785 : 0
< 11786 : 0
---
> 11785 : 1
> 11786 : 1
11789,11790c11789,11790
< 11788 : 0
< 11789 : 0
---
> 11788 : 1
> 11789 : 1
11805,11806c11805,11806
< 11804 : 0
< 11805 : 0
---
> 11804 : 1
> 11805 : 1

I was hoping to use java.lang.Character.isMirrored(char), but the above is the result of diffing the output for jython and python running my test and diff-ing the output. Looking in more detail, Java 1.4 supports UCD 3.2, then Java 5 and Java 6 both only have support for UCD 4.0.

jabley@miq-jabley ~/work/eclipse/workspaces/personal/jython-trunk/jython
$ python
Python 2.5.1 (r251:54863, May 18 2007, 16:56:43)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import unicodedata
>>> unicodedata.unidata_version
'4.1.0'

And I'm getting the sneaking feeling that I've done something like that before, but it's been so long since I did any development in this area that I've forgotten it!

Tuesday, June 26, 2007

Career Development

Steve Yegge's recent post about the second most important course in CS made me smile. I discovered Eric Raymond's How To Become A Hacker fairly early on in my career, and to a Mathematics graduate with a job doing Visual Basic 6.0, that was eye-opening stuff. But you always have to remember that all authors have an agenda (including this one, obviously - Ed) and it has been commented by people other than myself that esr's HOWTO could be alternatively titled 'How To Be Like Eric Raymond'. Well, so be it. It's always the journey that's the interesting part. So can we consider Steve's post to be an equivalent 'How To Be Like Steve Yegge'? Doesn't matter. Again, it's the journey that has value.

As an aside, I had an email from Amazon today.

Your order #xxx-xxxxxxx-xxxxxxx (received 27-March-2007)
-------------------------------------------------------------------------
Ordered Title Price Dispatched Subtotal
---------------------------------------------------------------------
Amazon.co.uk items (Sold by Amazon EU S.a.r.L.):

1 Compilers: Principles, Tec... £47.49 1 £47.49

Shipped via Home Delivery Network Limited (estimated arrival date:
28-June-2007).
Note the order date as well. Three months to get that book. Ouch! But at least it's given me time to read these two, and I can interpret Steve's post (and Joe's comment) as a good barometer of where I'm heading.

Thursday, June 14, 2007

Jython Update - actually doing some work on UnicodeData

So I had put this on hold to finish reading Josh Bloch and Neal Gafter's Java Puzzlers. Great book; highlighted some new things for me, which is all I ask for in any book. Partly that is since I'm still not doing Java 5 apart from at home for various minor things, but it was good.

So now back to Jython, finally. Well, reasons for my procrastination first:
  1. New Job - busy as hell.

  2. New job comes with a new laptop, which I was hoping would be a big step up from my nearly six year old self-built machine. The new laptop has reasonably impressive hardware specification, but it's running Vista. What an absolute pile of shit. I honestly don't know how developers are productive using that OS. I've given it nearly two months, just to be sure that it's not the fact that I've been off Windows for three years that is causing me all of the problems, but really. It's got to the point where I'm looking seriously at Xen on Ubuntu for the odd application that I do need to run Windows for. The other alternative would be to install XP, put up with the half life cost and initial downtime of getting the laptop set up for development all over again. I'll enumerate my grievances in a separate post. I don't think XP would get in my way as much as Vista (I did knock up the xmlunit XMLSchema validation patch on my wife's XP machine over Christmas and it wasn't that painful), but I'm not a fan of Windows after using GNU/Linux exclusively for three years.

So I've been doing a little work on UnicodeData again. Since I've not touched it for so long, I wanted to get some code up and running to start seeing how many tests were failing. Until Jython goes to Java 5 and above, I can't use java.lang.Character to do parts of it, or I could do a piecemeal approach of use java.lang.Character for the BMP, and then implement a new part for supplementary characters, or try to provide behaviour based on the running JVM. All a bit more work than I wanted to do, laziness and hubris being key. Instead, go for the brute force approach of the simplest thing that will possibly work. So I wrote a Python script (what else - it's a nice way of bootstrapping this problem) to parse the UnicodeData.txt file and generate some Java classes. The initial approach was to partition the UnicodeData.txt into a class for each plane in Unicode. Anyone that knows Unicode and the assigned codepoints will know that the BMP will take up most of this, but I was interested in getting something working, and then maybe refine it once the tests are passing. Well, my first cut was to have a simple interface:


interface UnicodePlane {

/**
* Return a UnicodeCodepoint for the specified codepoint.
*
* @param codepoint the Unicode codepoint
*
* @return a UnicodeCodepoint, or null if there is no match
*/
UnicodeCodepoint getCodepoint(int codepoint);

}


I would have a class that implements this interface for each plane and a static initializer within each class that fills a Map of UnicodeCodepoint classes keyed by Integer codepoint.

Eclipse gives me this error:


The code for the static initializer is exceeding the 65535 bytes limit


Whereas ANT gave me this variation:

[javac] Compiling 2 source files to c:\Users\jabley\work\eclipse\workspaces\personal\jython-trunk\jython\build
[javac] c:\Users\jabley\work\eclipse\workspaces\personal\jython-trunk\jython\UnicodeData\generated-src\org\python\modules\unicodedata\UnicodeCharacterDataBasicMultilingualPlane
.java:11: code too large
[javac] private static final Map CODEPOINTS = new HashMap();
[javac] ^
[javac] 1 error

BUILD FAILED
c:\Users\jabley\work\eclipse\workspaces\personal\jython-trunk\jython\build.xml:456: Compile failed; see the compiler error output for details.

So I need to think a bit harder about the data structures. Turning to Bentley's Programming Pearls, the sparseness of certain items stands out, like the mirrored property.

I'll have a think. At least with the Python script that I have to cut up the UnicodeData.txt file, it's very easy to add another list comprehension to it, to see how many items in the file exhibit a certain property. The other way I'm considering is to just generate a properties file and lazily populate a Map as required. That's probably what I'll try next, rather than thinking too hard about how to compress a 1038607 bytes data file into something more reasonable.