Sometimes it's very enlightening to look back at the beginning of a project to see how things got set up and how we started down the path that led to where we are today. In this post, I'm going to talk about the first ten tickets we created at World Singles as we kicked off our green field rewrite project five years ago.
Entries Tagged as clojure
June 03, 2014 · 4 Comments
May 20, 2014 · 6 Comments
I love conferences but I can't attend all of them...
February 13, 2014 · 3 Comments
A very short post, partly as a reminder for my future self. Check out the following Leiningen plugins:
- lein-ancient - analyzes your project.clj and lets you know which dependencies are out of date.
- lein-exec - directly execute Clojure code snippets, or write shell scripts in Clojure!
- lein-try - start a REPL with various dependencies without needing a project. Great for exploring new libraries!
- Eastwood - a lint tool for Clojure.
January 31, 2014 · No Comments
I've been an advocate of diversity in IT for a long time. I'm very pleased to work in a company that has an above average ratio of female to male employees, as well as very diverse cultural backgrounds amongst our staff. In most tech communities, diversity is pretty low. It's why organizations like RailsBridge and Women Who Code and numerous others exist. The lack of diversity hurts us all because a homogeneous community doesn't have diversity of thought either: diverse teams outperform homogeneous teams.
Back in 2012, I became very bothered by the lack of diversity in the Clojure community - it's a lot less diverse than several other communities I've experienced - and after talking to a few people, I reached out to a former colleague from Macromedia, Sarah Allen - president of RailsBridge, to see what it would take to get something started to address it. I continued talking to people about the idea of ClojureBridge and was thrilled when Bridget Hillyer, Lynn Grogan, Maggie Litton and others took up the torch to make it happen!
I'm even more thrilled to announce that ClojureBridge is a reality: you can sign up on the web site to get involved, you can join the ClojureBridge Workshops mailing list. The first workshop will be in Durham, NC the first weekend of April and the second workshop will be in San Francisco, CA the first weekend of May!
As it says on the ClojureBridge web site:
ClojureBridge aims to increase diversity within the Clojure community by offering free, beginner-friendly workshops for women.
Our students range from those completely new to programming to professional developers who want to learn more about Clojure.
ClojureBridge is inspired by RailsBridge, and closely models the RailsBridge philosophy.
January 31, 2014 · No Comments
clojure.java.jdbc 0.3.3 is a minor bug fix release:
- JDBC-89 - calling query with a bare SQL string no longer causes an exception (or a crash with some drivers!).
- JDBC-87 - metadata-result is no longer lazy by default, and accepts :row-fn and :result-set-fn arguments, like query, to manipulate the result set.
- Key/value pairs in connection string URI are now passed through to the driver as part of the connection parameters - thanks to Phil Hagelberg for that.
January 10, 2014 · 4 Comments
Early in 2012, Chris Granger - former Program Manager for Microsoft's Visual Studio product, Bay Area resident, and Clojure enthusiast - released a proof of concept video for something he called "LightTable", a radical rethinking of our traditional programming environments. Over the next few months, new videos appeared, followed by a KickStarter project...
LightTable is still young but it is already a usable editor with some very unique features. Over the last year I've kept dipping into LightTable to see how it is evolving but it's been too rough around the edges, and too feature poor, to use for anything more than small projects for short periods. It's always shown tremendous promise though so I knew it was only a matter of time...
...and with the new release, and the plugins available, today I was able to use LightTable for all of my editing needs (and I'm writing this blog post in it as well!). Today I've been exploring the Monger library for MongoDB. We've been a CongoMongo shop for a couple of years but there are all sorts of reasons why we're concerned about continuing to rely on that library (and I'm pretty much the de facto lead on the project!). LightTable's live evaluation and inline documentation make it really easy to explore and play with new libraries and to evaluate how a particular library will work with your code.
As I said, LightTable is still young. The plugins available so far are pretty basic. I'm an Emacs user so I'm used to full keyboard control, integrated Git, and a whole bunch of powerful packages. That said, LightTable is already doing well: the Emacs key bindings are usable (but still quirky), there's a great REPL experience, rainbow delimiters and the Claire plugin provides a good first step toward the ido-mode C-x C-f experience. Git integration is the biggest missing piece for me right now. Global find and replace. An integrated shell. And an IRC client would be icing on the cake.
So I can't leave Emacs behind yet. I doubt I'll be able to leave it behind for a while. But I expect I'll be able to use LightTable for more and more serious work going forward.
December 30, 2013 · No Comments
This release contains minor bug fixes compared to 0.3.0, with the main focus being an overhaul of docstrings etc to improve the auto-gen'd documentation.
The community documentation for java.jdbc on clojure-doc has also had a major overhaul.
Details of this release:
- Add nil protocol implementation to ISQLParameter.
- Improve docstrings and add :arglists for better auto-generated documentation.
- Make insert-sql private - technically a breaking change but it should never have been public: sorry folks!
- Provide better protocol for setting parameters in prepared statements JDBC-86.
- Fix parens in two deprecated tests JDBC-85.
- Made create-table-ddl less aggressive about applying as-sql-name so only first name in a column spec is affected.
Please note that the 0.3.1 release is broken and should not be used.
December 17, 2013 · No Comments
The "gold" release of the Clojure contrib library that wraps JDBC is now available on Maven Central. This release has been in the works for most of this year, as it introduces large changes from the previous "gold" release (0.2.3) that aim to make the library more idiomatic and easier to use in a multi-threaded functional environment. In order to provide a smooth migration path, the old API from the 0.2.3 release has been moved wholesale to the clojure.java.jdbc.deprecated namespace, and the new API in 0.3.0 uses new naming for almost all of the (new) functionality.
The main API change is the removal of the dynamic global variable *db* and the with-connection macro. Instead you now pass the database spec as an explicit argument in all calls, and you can share connections across multiple SQL operations either by using connection pooling (recommended) or the new with-db-connection macro that takes an explicit binding for (a connected version of) the database spec.
A common problem with the old API when performing queries was that with-query-results required care because the result set was lazily constructed and it was easy to let that lazy sequence escape and have the connection closed before you had finished working on the results. The new API provides a query function that, by default, fully realizes the result set to avoid that problem. You can still process very large result sets lazily by passing :row-fn and/or :result-set-fn arguments to query.
For more details of the new API, you can read the reference documentation for clojure.java.jdbc. For a summary of all the changes made since the 0.2.3 release, read the clojure.java.jdbc change log on Github. To use the library in your project, see the clojure.java.jdbc dependency information on Github.
Detailed documentation on using clojure.java.jdbc is being developed for the Clojure Documentation Site and will be found in the java.jdbc section of the Clojure ecosystems area, once the site has been refreshed from the markdown sources on Github.
December 13, 2013 · No Comments
Clojure's low-level JDBC wrapper inches closer to a gold 0.3.0 release with the first release candidate. Read more on clojure.java.jdbc's Github repo. The changes in this release are:
- Deprecate db-transaction (new in 0.3.0) in favor of with-db-transaction JDBC-81.
- Add with-db-metadata macro and metadata-result function to make it easier to work with SQL metadata JDBC-80.
- Add with-db-connection macro to make it easier to run groups of operations against a single open connection JDBC-79.
- Add ISQLValue protocol to make it easier to support custom SQL types for parameters in SQL statements JDBC-77.
- Add support for :isolation in with-db-transaction JDBC-75.
- Add :user as an alias for :username for DataSource connections JDBC-74.
November 24, 2013 · No Comments
Based on feedback from the community, I have released clojure.java.jdbc 0.3.0-beta2 to Maven Central.
This includes two very important changes:
- The clojure.java.jdbc.sql and clojure.java.jdbc.ddl namespaces have been removed.
- The API functions that were already marked as deprecated have moved to the clojure.java.jdbc.deprecated namespace
This means that if you depend on the clojure.java.jdbc.sql or clojure.java.jdbc.ddl namespaces, which were introduced in 0.3.0-alpha1, you will need to switch to the java-jdbc/dsl project (release 0.1.0 is on Clojars). The new namespaces in that project are java-jdbc.sql and java-jdbc.ddl. If you depend on these namespaces, I strongly recommend you migrate to a more sophisticated DSL, such as:
- HoneySQL - https://github.com/jkk/honeysql
- SQLingvo - https://github.com/r0man/sqlingvo
- Korma - http://www.sqlkorma.com
More importantly, if you depend on the older (0.2.3) API in clojure.java.jdbc, you'll need to switch to the clojure.java.jdbc.deprecated namespace in your code, until you can migrate to new API in clojure.java.jdbc instead.
These steps are more radical than I would have liked but they simplify the library and streamline the API - and the auto-generated documentation - which should reduce all the confusion expressed about the library right now. This will allow the library to move forward in a more focused manner, with an API that no longer depends on dynamic variables.