I recently needed to convert a PostgreSQL UUID to bytea, and couldn’t find any quick one-liners on the web. So here it is, for your enjoyment:
Front Street uses web storage (specifically localStorage) to store persistent user data. To make the cache as effective as possible, it should be able to grow to use as much space as it can. However, we also store other information in localStorage, like user session information (the user’s login token and list of teams, for example). That means if the cache grew to use all the localStorage space, the app couldn’t function properly. Thus, we needed a way to detect the size of localStorage so we could partition localStorage between cache and session information.
Unlike Process Street, MailTheme will be running on Google Cloud and, for the time being, won’t be behind a load balancer or proxy. As such, I needed to make all HTTP requests auto-redirect to HTTPS via Play. This turned out to be more difficult than I first imagined, as Play prior to version 2.3 has no way to detect whether or not the incoming request is over SSL.
We are looking for a team member to join as a co-founder for a new startup called Process Street. Process Street is building a collaborative process management system targeted at the SME market.
We are a brand new startup, working to build our MVP. We currently have 2 of our desired 3 “Dream Team”. We have our Hustler (business/marketing) and our Hacker (coding/sys-admin), we just need our Hipster (UI/UX) co-founder to help make our dream a reality.
We are Australian and Canadian and the company is based in Delaware, USA, but we are living and working in Buenos Aires, where we plan to build out the initial product and work on doing market testing and gaining traction. If everything goes well, we plan to move to San Francisco (Silicon Valley) to scale out the business.
When implementing an HTML form that requires validation, a developer must make a decision: should I use client-side validation, server-side validation, or both?
In this article I will give a quick overview of the pros and cons of these validation techniques, as well as introduce my solution to the problem: Pajama.
I was looking at a Software Developer posting on the FreshBooks careers page the other day, and near the end of the “How to apply” instructions there was a curious sentence:
“If you want to prove you’re really paying attention, include a verse of ottava rima and a link to your GitHub profile with your application and you’re guaranteed to have your application reviewed by our Software Development Manager.”
I’d never heard of the ottava rima rhyming stanza form before, but a quick trip to Wikipedia remedied that. Essentially, an ottava rima stanza must satisfy three rules:
- Each stanza must have 8 lines,
- The lines must be iambic pentameter,
- The stanza must have the rhyming format a-b-a-b-a-b-c-c.
Here is an example of an ottava rima stanza by Frere (as given in the Wikipedia article):
But chiefly, when the shadowy moon had shed
O’er woods and waters her mysterious hue,
Their passive hearts and vacant fancies fed
With thoughts and aspirations strange and new,
Till their brute souls with inward working bred
Dark hints that in the depths of instinct grew
Subjection not from Locke’s associations,
Nor David Hartley’s doctrine of vibrations.
The simplicity of the rules got me thinking: how hard would it be to write a program to check if a poem stanza is ottava rima?
In this article, we will write a simple ottava rima detector in PHP.
Cookies are ubiquitous on the web. They’re used to store usernames, login tokens, shopping cart contents, and so on. In libraries, cookies are typically modeled as name-value pairs. An API consumer requests a cookie using a known name (e.g.
$.cookie('user') in jQuery with the Cookie plugin) and the library returns a string (e.g.
When it comes time to work with XML in Java, the first thing I usually do is go to the JDOM website to check for a Java 5 update. Unfortunately, I am always disappointed. There has not been a major JDOM release in over 6 years and, if the JDOM mailing list is to be believed, no Java 5 version is planned. As a result, I have decided to take my own initiative and make CoffeeDOM, a JDOM fork with Java 5 support.
CoffeeDOM is intended as a natural evolution for JDOM developers. As such, there have been minimal changes to the API. CoffeeDOM adds support for Java 5 features like generics, enums, and covariant method return types, and reduces the amount of boilerplate required by making previously checked exceptions (like JDOMException) unchecked. In this article, I will briefly go over these changes.