"Database Developer/Reporting" according to my agency.
"Data Analyst" according to my coworker, who's been trying to keep me in-line...
I use using Perl and Oracle these past two weeks. (Haven't done much but setup stuff and complain about how badly written the old perl modules are and how confusing the database is).
I've been bragging to the best Perl programmer in the area at work (I'm guessing) that I've not been sure whether I'm a perl-fan so much anymore these last few years, preferring instead to have a fascination with functional programming languages (eg. OCaml, F#, Haskell, Haxe, Scala, maybe Erlang, Clean-language, ATS), but that is a sort of programming idealism that is hard to explain to people at work. Essentially, I think software should be as close as possible to "provably-correct" or even proven-correct (as in the seL4 Linux-like "verified" operating-system kernel, http://www.ertos.nicta.com.au/research/sel4/ ), and I think strong-typing and rich type-systems like Haskell's are a step in the direction of development of such software.
But programming-language idealism aside, Perl is very utilitarian, and may be the best tool for the job of running ad-hoc and scheduled reports against databases in a minimal amount of code, so I've been finally learning some basics that I've ignored in the past, like how to use packages and modules, and objects. I know, "duh! How could you call yourself a perl programmer if you don't know those basics?" Well, I wrote Streetpulse's import system in Perl in 2005, and a couple of scripts a few hundred lines long with very little to no modularization were far superior to the old ColdFusion scripts, so it worked well enough for my needs without knowing/using o-o or packages/modules.
As for o-o perl, the idea of blessing a hashtable to magically turn it into an object has felt rather foreign to me. Perhaps I should be using Moose just to give any classes I may create a consistent declaration structure...
I suppose if I want to be a programming-language idealist, I should install Perl 6 (Rakudo) and start using that. I've installed it, but probably won't use it in the immediate future. I don't know who is going to take the plunge and actually adopt Perl6 in a substantial way, but I suppose it could achieve critical mass sometime in the next few years. I think it may take either adding a few killer features or developing some killer libraries that actually need Perl6 features, before serious adoption begins. For example, some sort of object/relational database interface, or a language-integrated query like LINQ or perhaps like HaskellDB. I think important parts of future software will be higher levels of abstraction and virtualization of services, and the database-interface should be abstracted-away as much as possible.
I think Haskell might be usable to develop efficient multicore software.But again, programming-language idealism aside, Perl is very utilitarian and I'm enjoying getting back to doing a little of it.
Hopefully I'll pick up some speed, and though I have never yet been what I would term a prolific coder, I'd like to approach that goal now. Perhaps if I design my vision for a reporting system for my department completely-enough up-front then I'll have something very usable in a few months, with a moderately-sized code-base. Maybe I'll even read a few books (for a change) to help develop some coding styles. I want to use a combination of functional and some O-O coding styles, and ideally design a DSL or some high-level perl modules. One thing I think I'll want to do is abstract away the joins in the database, because it seems to be overly hard to construct queries due to a set of awkward relationship tables.
Eventually I want to work on ERP and/or workflow software. implementation and/or integration... this is related to an idea I've had for over a year, but that's another story...
(I might) Consider Clean-Language's workflow system as a possible model to imitate or start with.
http://wiki.clean.cs.ru.nl/Clean iTaskI was thinking, for example, how when I join a company through an agency, I may have to use 2 or more time-recording (timesheet) tools, and how workflow management system and client application could eliminate that necessity.
On 10/27/2012 8:13 AM, Joshua ben Jore wrote:
Most places I know just call this sort of beast a "Software Engineer." Amazon will stuff it up a bit with "Software Development Engineer." Josh On Fri, Oct 26, 2012 at 3:16 PM, Tyler Hardison <[email protected]> wrote:So I'm trying to get a poll of what people's titles are. Particularly if they're primarily working in Perl, SQL, Web, and engineering? Even more helpful if you're forced to work in other languages such as those out of the evil empire®. Mainly I guess I'm trying to define what I do in an all encompassing title: Linux SysAdmin (Only as needed for setting up dev environments) Can compile Perl from scratch as needed. Understands threads. Uses Moose. Can whip up a Dancer app front-ended by nginx for SSL. Can debug a .NET app if I'm help at gunpoint. Can take a spec from a customer and wow them. Understands Agile. etc. --t _____________________________________________________________ Seattle Perl Users Group Mailing List POST TO: [email protected] SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list MEETINGS: 3rd Tuesdays WEB PAGE: http://seattleperl.org/_____________________________________________________________ Seattle Perl Users Group Mailing List POST TO: [email protected] SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list MEETINGS: 3rd Tuesdays WEB PAGE: http://seattleperl.org/
<<attachment: tallpeak.vcf>>
_____________________________________________________________
Seattle Perl Users Group Mailing List
POST TO: [email protected]
SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list
MEETINGS: 3rd Tuesdays
WEB PAGE: http://seattleperl.org/
