Neo4j has made many changes and improvements in its server and its query language in that time. However, as it has become successful commercially, it has made breaking API changes of one kind or another more and more regularly. In the last major release, version 4.0, Neo4j retired the REST endpoint on which REST::Neo4p was based. This endpoint was "entity-based", as it were, allowing direct access to nodes, relationships, and the like via entity IDs. It was well suited to the object (HAR HAR) of REST::Neo4p. But Neo4j decided to focus exclusively on its declarative query language Cypher, and to move away from the "graph walking" paradigm that the REST endpoint represented.
It was at this point that I hoped that REST::Neo4p could finally go on to its heavenly reward. But, alas, there were folks still using it who were bummed that it didn't work with 4.0. Thankfully, Arne Johannessen (AJNN) created Neo4::Driver, that does an excellent job of realizing the latest Neo4j "language driver" conventions. It also is based on the new server's so-called "HTTP" endpoint. This endpoint should last for at least a couple of years.
Thanks to Neo4j::Driver, REST::Neo4p 0.4000 can be used with Neo4j 4.0+ (as well as earlier versions with the HTTP endpoint), with almost all of its object mapping features in place. Ideally, it should just work with 4.0. If it doesn't, please create an issue.
The Neo4j::Driver "agent" in REST::Neo4p is really an emulation, using Cypher queries, of a large fraction of the original REST API. It probably is the limit to which the ideas can pushed. From here, Neo4j::Driver is the way forward in Perl 5, based as it is on declarative queries.
I hope the latest version will help those few folks who have come to REST::Neo4p over the years make the transition. It should allow you to avoid replicating your working code with a ton of irritating little frigging cypher queries everywhere. Since I did it. Yes, I do want a medal. Or maybe a fish slap.
By the way-- Neo4j's custom protocol over TCP - called Bolt - is a key component of their architecture, and I expect that the Bolt endpoint will ultimately rule them all. Arne and I are working on that; see, e.g., Neo4j::Bolt. A topic for another time.
glhf
]]>$ cd myscripts/500line $ svn import -m 'my import' \\ https://notworkrelated.googlecode.com/svn/trunk . \\ --username you@gmail.comThe '-m' option is a comment that will be added to your commit log. In general, every change you commit will require a comment. This is a Good Thing.
$ cd .. $ svn checkout https://notworkrelated.googlecode.com/svn/trunk \\ notworkrelatedYour code is now checked out into the 'working directory' myscripts/notworkrelated.
$ touch empty.file $ svn add empty.fileAdd a whole directory structure, same command:
$ mv ../otherstuff/otherscripts . $ svn add otherscriptsIf you need to delete a file or directory, use the 'del' = 'rm' command.
$ svn rm old.pl~which will delete the file and schedule it for 'deletion' in VC (i.e., the file will not appear in the latest version of your code for check out. You can get it back if you need it later.)
$ svn mv -p otherscripts aux/otherscriptsHere, svn mv creates the new parent directory 'aux' and the leaf 'otherscripts'. In your working directory, you have moved 'otherscripts' and its contents to 'aux/otherscripts'. You have also scheduled './otherscripts' and its contents are for deletion in the repos, and 'aux' and all of its new contents for addition. 'Scheduled' again means these events will happen the next time you...
$ svn commit -m 'You must add a comment...get used to it'Now, work, commit, work, commit, ad infinitum. Commit early and often. Every so often, see how much work you've done:
$ svn log ------------------------------------------------------------------------ r226 | maj | 2013-08-30 23:28:10 -0400 (Fri, 30 Aug 2013) | 1 line working on exception formatting ------------------------------------------------------------------------ r225 | maj | 2013-08-27 22:39:19 -0400 (Tue, 27 Aug 2013) | 1 line propsets ------------------------------------------------------------------------ r224 | maj | 2013-08-27 22:21:06 -0400 (Tue, 27 Aug 2013) | 1 line added spatyper lib and t; propset on everything ------------------------------------------------------------------------ r223 | maj | 2013-08-25 22:47:36 -0400 (Sun, 25 Aug 2013) | 1 line adding Mojo tests ------------------------------------------------------------------------ r222 | maj | 2013-08-23 22:36:13 -0400 (Fri, 23 Aug 2013) | 1 line inspect template is workingIt's a good feeling.
You say, "No need to waste my time, only people who work in teams need that."
Version control
The pro devs here will say, why is he even talking about this? I'm addressing those of us who have a 500 line script in a directory called 'stuff/myscript/myscript2'. There's no excuse anymore, for individuals, not just teams, not to version control their software. Use Google Code, Github or any free service and start learning the drill. You've experienced the blessing of version control if you've ever pushed the up-arrow at the command line; why not apply that to your entire personal codebase? I will discuss this more in an upcoming post.
Write tests
You already write tests. You give your script some file and see if it borks. You set some variable in the debugger (Perl has a built-in debugger, some other post...), and see if you get the right answer. What if you could capture those in code and run them whenever you want - say, when you add some new function or option, and make sure that the answers are still right? What if you could do this without retyping from your lab notebook? This is what writing software tests is about. Modern Perl provides excellent support for creating and running automated tests in Test::More and related modules. More on this upcoming.
Create distributions
Let's revisit the 500 line script, and your boss asking you rerun it on the new data. If the 30 subs were organized into modules, you would have better luck identifying what you need to modify. Put those in a directory always called 'lib', and you don't have to remember stuff/myscript/myscript2. Write a script that's a true script-- that glues together the functional components in the modules. Put it in a directory always called 'bin' or 'scripts'. Already you can maintain your code better = save yourself time and stress. Now, the best part is that Perl (in the form of ExtUtils::MakeMaker or Module::Build, e.g.) understands, enforces, and even can automatically set up this structure for you. Built in are facilities for running those tests you've written, installing your script and its modules in Perl-standard places, and packaging the whole thing. You're not only organized, but you can share your work instantly, and set it up anywhere. More upcoming.
There is a learning curve here, no question. But you will obtain immediate benefits. Better than this, however, is that the change in perspective you get will allow you to see and realize more potential in your work. You will be able to collaborate more ('Oh, I've got a module that does that.'), and have more to offer ("I'll send you the distro; type make, make test and make install and you're all set"), and gain more glory ('Thanks, you rock!'). You'll also be held accountable ('But dude, it crashes on binary files'), you can easily make it good ('Quick fix and a new test; here's the distro'), and your future quality will improve ('Oh, I've got an improved module that does that...').
Even better than this, you will start to see yourself as part of the community of developers and get the itch to get involved in it, to everyone's benefit.
It's too bad so many in my line of work (bioinformatics) say they "know Perl", but continue to write translated C and fill their code with &functions. Fine, TMTOWTDI, but there is room for personal growth. Problem is, this is the kind of coding that perpetuates the myth that Perl is somehow antiquated, unable to deal with modern problems or find a place in the ecosystem of languages. Sharing the fun of Modern Perl here with my colleagues and others is one small effort to help turn this tide.
I won't claim to have deep insights. I won't be able to back up my love of Module::Build with a cogent flameproof argument. I'll being trying to make my Perl more sophisticated = more maintainable, more readable, more shareable, and basically cooler, and I'll share what I learn as I can.
]]>