Markdown in Blogger

For a long time I was upset with lack of native support of Markdown in Blogger. Both manual editing of HTML and lame WYSIWYG editor are counter-productive. Recently I finally had time to search for solution - and here is almost a silver bullet: StackEdit. It can be used on-line or installed as a Chrome Plugin. This is the first post written with StackEdit.

For me it worked like this - hope that by the time you read it StackEdit will be further improved and it will be a bit simpler:

1. Install plugin
2. Create folder in GoogleDocs (unfortunately not available in StackEdit itself) and set up its synchronization in StackEdit (#/Synchronize/)
3. Create folder for blog entries on local storage via StackEdit
4. Create some document in StackEdit, write its content
5. Unfortunately there’s no option to customize folder on document creation - so it has to be moved manually to spedific folder. Both in StackEdit and in GoogleDocs separately - unlike document content, location isn’t synchronized automatically.
   1 Publish the document on Blogger (#/Publish/Blogger)
6. Go to Blogger and specify tags - unfortunately I didn’t find means to assign it directly from StackEdit
7. If you edit the document and want to re-publish it - #/Publish/Update publication. Nice that StackEdit remembers where you’ve published it last time

Sbt repository authentication

Here is brief instruction how to access repositories protected by basic authentication from sbt - checked with version 0.13. That's how one would configure custom repository in .sbt file:

resolvers ++= Seq(
..
  "MyRepositoryName" at "http://repository.host.com/nexus/content/repositories/releases",
...
)

If repository requires authentication - sbt would just show rather meaningless warning and claim that artifact isn't found:

[warn] ==== MyRepositoryName: tried
[warn]   http://repository.host.com/nexus/content/repositories/releases/... here goes path to artifact ...

You'll need to know authentication realm returned by repository server in order to configure credentials. Realm can be found in WWW-Authenticate header of response - for example in output of following command:

curl -X GET -v http://... here goes attempted URL from sbt log warning ...
....
< WWW-Authenticate: BASIC realm="Repository Realm"
....

There are 3 options for specifying credentials: directly in .sbt file or in separete file (usually in home directory).

1. In project .sbt file:

   credentials += Credentials("Repository Realm", "repository.host.com", "username", "password")
   

   But there's obvious drawback - you'll need to publish your password under version control system.
2. In global settings file Open (or create if not exist) file ~/.sbt/0.13/global.sbt and add to it just the same line that you would add to project sbt
3. In credential file Didn't try it because previous option seemes more attractive to me. You'll need to specify path to this file in project .sbt file. You can find some clues in Publishing section of Sbt documentation and on StackOverflow

H2 LIMIT and OFFSET

Funny thing - H2 in PostgreSQL compatibility mode requires that OFFSET should go strictly after LIMIT (like LIMIT 25 OFFSET 50). Otherwise it can't parse the query:

error in SQL statement "SELECT ..........   OFFSET 0  LIMIT[*] 25 "; 
expected "[, ::, *, /, %, +, -, ||, ~, !~, NOT, 
LIKE, REGEXP, IS, IN, BETWEEN, AND, OR, ROW, ROWS"

Scala protected methods aren't that much protected

Just discovered weird behavior of Scala's protected methods: they're actually compiled to public methods in byte-code. Therefore if you try to override them in Java code with another protected method compilation will fail with something like this: "attempting to assign weaker access privileges; was public". After some googling I've discovered that other people also spotted this issue. I think such weird compiler behavior was needed because of access level mismatch in Scala and Java - but I thought that Scala's protected is more restrictive then Java's. So I'm yet to figure out reason of such behavior. By the way, package-level protected (like protected[yourpackage]) is also compiled to public - at least for Scala 2.10.0

Integration test sources with eclipse-sbt

Finally found this answer: http://stackoverflow.com/questions/23229864/how-can-i-show-a-source-directory-to-sbteclipse-without-adding-it-to-the-compile to a question: how to include integration test sources in Scala IDE (Eclipse) - just add the following line to your build.sbt:

EclipseKeys.configurations := Set(Compile, Test, IntegrationTest)

Error: Multiple ResultSets were returned by the query

Turned out that error "org.postgresql.util.PSQLException: Multiple ResultSets were returned by the query" may be caused by semicolon (;) in the end of the query when working with Postgres via JDBC