A long while ago, someone (it was too long ago, so I sincerely forgot who, it probably was in the JBuilder era) told me that I should try out Ruby and Scala.
I did take a short look at Ruby back then, but since Ruby was so focussed on Web Development, and my heart really wasn’t there, postponed it to the times that the Web would be hot for me.
Then I should have taken a look at Scala (which compiles to Java bytecode), but since I abandoned Java (JBuilder wasn’t nice, Java programming was slow and modern IDEs like IntelliJ IDEA and Eclipse weren’t there yet).
Now that I’ve done truckloads of work in the .NET and Delphi world (including domain specific languages and Pascal based products), I bumped into these Scala videos by Venkat Subramaniam:
AOP allows you to perform separate of concerns (SoC) in your application, especially in the area of cross-cutting concerns like for instance logging, authorization, monitoring, etc.
It took a while in Delphi to allow for AOP, but the TVirtualMethodInterceptor (that introduced in Delphi 2010) can be used to do AOP (only for Virtual Methods, which is still way better than having no AOP at all).
The code requires a lot of manual labor. so I was glad that DSharp (a great library by Stefan Glienke – one of the leading Spring4D contributors) contains a nice wrapper around TVirtualMethodInterceptor so you can use AOP in an attribute based fashion.
Nick Hodges recorded a good introductory video on AOP in Delphi with slides and demo code:
I needed to get an existing Git repository to a client that had a tightened network. No SSH allowed, web proxy filtering out all sorts of sites and also performing a HTTPS man-in-the-middle to detect and reject all kinds of binaries, etc.
In order to create a new Git repository from an existing repository one would typically create a new bare repository and push one or more branches from the existing to the new repository.
The trick is to know that server-side repositories are `bare` and client side repositories are `regular`. `bare` means the absence of a working copy on the server side.
Git can do SVN, so locally you will see it as a Git repository, but the SVN repository will stay “as is” and not be affected neither will other SVN users be affected.
Two of the great benefits of this:
You have fill local history so no need for long server-round trips to access it.
You have the full query featureset of Git at your disposal. Locally.
Combined, you can do these without the need to be online or wait for the SVN connection and transfer: