http://qs321.pair.com?node_id=11103968

jfrm has asked for the wisdom of the Perl Monks concerning the following question:

My situation is unusual. I started a company around 15 or so years ago and it's grown now so there are 4 employees, probably soon more. The website, order system, stock tracking system, product database and a heck of a lot more was and continues to be all written by me in Perl - quite badly in places. This collection of scripts is more than central to the company - it runs everything.

This is not sustainable so I'm hoping to hire a Perl developer to assist me with bug fixing and new development work (email me if you're interested, btw...!). The job can probably be done remotely but regardless I will need to set up a suitable development environment. I'm ashamed to say that I work directly on our local system (although never the live website), sometimes while people are using it. I do appreciate that this is extremely bad and I must be chastised strongly for being very naughty. Still, it works for me.

But it won't work for someone else - so I need to set up a suitable development environment for a proper developer to code, test and then when ready move it to the live environment. And I have absolutely no experience of this; I've just learned Perl on the fly as I needed to. So that's my problem - what does a good (but simple and straightforward) development environment consist of that will keep a Perl developer in good spirits?

The environment is Windows with MySQL 5.15 and Apache 2 with ActiveState Perl 5.16. I use a variety of libraries but a lot is done in Rose::DB. Currently I just code in Komodo Editor and search using a file scanner to find what I need. There is no development studio or anything. I presume the developer will need a development server to play with on top of the machine that he/she uses and then we would need a way of migrating new code to the local live server. But beyond that hazy conjecture, I really haven't got a clue where to start. Is source control a requirement? Can I use Visual Studio? How do I keep the development MySQL schema in synch with the live one?

So, having bared my soul - is there any monk who can advise how I can ascend from the dark side to the light and repair the sad situation that I have created? Any tips would be much appreciated...

Replies are listed 'Best First'.
Re: What is a good, straightforward Perl with Mysql development environment?
by davies (Prior) on Aug 05, 2019 at 18:09 UTC

    I can find no reference to MySQL 5.15. AFAICT it jumped from 5.7 to 8.0. If you meant 5.5.x, then your version is out of support and you should be planning an upgrade.

    Your Apache version number is not precise enough for me to tell, but if you are not on 2.4.x, you should again be looking to upgrade.

    Your Perl version is not a problem (although 5.30 is available), but I found some years back that Strawberry Perl was more convenient on Windows than AS, although I used that for a decade or more. If you are using things that have been deprecated or removed in later versions, though, that is something to beware. Removals and deprecations usually happen for good reasons.

    Source control is not a technical requirement, but most developers use it because they have the scars. The precise product is personal preference, but you may struggle to find developers who have never used git.

    Editors, studios and the like are personal preference. You mention Visual Studio and I am pretty confident that you can use it, but what are the advantages that you expect from it?

    I had never heard of Rose::DB before, but it seems to be a simplified version of DBIx::Class. I see no updates for three years, but that is not necessarily a problem.

    It is a long time since I worked with the synchronisation tools of MySQL, but it used to come with lots of replication tools and I would be astonished if there were nothing built in to keep the two schemas in sync.

    You are trying to run a business and write code at the same time. That puts a lot of strain on your priorities. But beware of masses of changes. Keep backups and don't change things unless you're sure that they won't cause breakages. This might be a time to do something cloudy - have your existing system running on one VM and your new one on another, replicating finctionality and doing a full scale parallel run. Cloud computing, of course, can be viciously expensive, but you might consider running a second hand server while major rewriting is in progress. Techbuyer are one supplier that I have seen at shows.

    I won't go as far as to say that you shouldn't change anything that works, but such changes should always be made very carefully.

    Regards,

    John Davies

      Thanks. Sorry, that should be MySQL 5.1.50. I am scared of upgrading but I know you are correct.

      Rose::DB::Object is brilliant and I can't recommend it enough. It makes database work so much easier.

        You scare because you don't test, The first thing you should do is install perlbrew and test your application in new environment. ;)




        I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction

Re: What is a good, straightforward Perl with Mysql development environment?
by Corion (Patriarch) on Aug 05, 2019 at 18:07 UTC
    How do I keep the development MySQL schema in synch with the live one?

    This for me sounds that you need to establish a ground source of truth, not only for changes to the DB schema but for all the other things too. Ideally you can build up a new environment from all the ground sources of truth and it will match the current state of the production environment.

    For an SQL schema, I would propose that all modifications to the schema go through SQL text files which are kept under source control and applied one by one. For example App::sqitch purports to do that, but you can also do it manually or with a script of your own.

    If you can keep to moving all changes to your production environment through text files source control, you can basically replay and replicate the environment everywhere where you can replicate your source control to.

Re: What is a good, straightforward Perl with Mysql development environment?
by 1nickt (Canon) on Aug 05, 2019 at 17:25 UTC

    Start by putting your codebase into Git or another RCS. Make a new release branch and start developing on that. When it is tested and stable, merge it to the master branch. Continue thus. That way things won't get any worse, and you lay the foundation for improvement.


    The way forward always starts with a minimal test.
Re: What is a good, straightforward Perl with Mysql development environment?
by talexb (Chancellor) on Aug 05, 2019 at 19:17 UTC

    All good suggestions so far, but I haven't seen any discussion about test suites. Ideally your code is separated into modules, each one with a decent set of tests, both unit tests (tests for modules as standalone units) and integration tests (tests for the modules working together).

    It's also a good thing if perlcritic is reasonably happy with your code base.

    If you have a way to stage your code in such a way that it's as close to the production environment as possible, great -- that'll give you an opportunity to road-test your code (after all the tests pass and code review).

    Probably the most important thing has already been mentioned -- get your code into a VCS, and make sure you have a really good handle on exactly what version is currently running in production.

    Alex / talexb / Toronto

    Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

Re: What is a good, straightforward Perl with Mysql development environment?
by holli (Abbot) on Aug 06, 2019 at 09:59 UTC
    How do I keep the development MySQL schema in synch with the live one?
    The MySQL Workbench can do it.
    There is a free replication tool named SymmetricDS, never used that though.
    Then there is HandyBackup which is also free, but requires to wipe the DB and reload all data on changes. As long as the data is not too big, that's not a bad route to take as it gives you a backup and easy bootstraping of the DB for free.
    There are multiple commercial solutions from affordable to very enterprisey. Notably SQLyog for $299/license.

    You definitly need a separate development environment. You may know all the pitfalls of the system, a newcomer won't. One wrong step and your production crashes, potentially losing or destroying data. Related to that, you need a good set of test data and a way to wipe and repopulate the (dvelopment) DB from that. The dataset should not be too big, but complete enough it covers all (edge) cases (customers with and without an address, with or out email address, etc.) and big enough to discover Schlemils, but not so big it slows test queries down too much.


    holli

    You can lead your users to water, but alas, you cannot drown them.
Re: What is a good, straightforward Perl with Mysql development environment?
by trippledubs (Deacon) on Aug 06, 2019 at 01:20 UTC

    Congratulations on a successful company! Tricky because there is no straight forward way to get from 'getting by' to bullet proof. Continuous improvement, I suspect. When you are interviewing candidates, I would ask them this question as you've described above.

    If all the data lives in the database, you could just have two databases, one for prod and one for dev. Actually Rose::DB shows a way to have two environments on the main page

    My::DB->register_db( domain => 'development', type => 'main', driver => 'Pg', database => 'dev_db', host => 'localhost', username => 'devuser', password => 'mysecret', server_time_zone => 'UTC', ); My::DB->register_db( domain => 'production', type => 'main', driver => 'Pg', database => 'big_db', host => 'dbserver.acme.com', username => 'dbadmin', password => 'prodsecret', server_time_zone => 'UTC', );
    # File: startup.pl use My::DB; if($ENV{'MYCORP_PRODUCTION_SERVER'}) { My::DB->default_domain('production'); } else { My::DB->default_domain('development'); }

    There are lots of ways to solve code deployment. In my experience, many outages due to problems in production that are unforseen or even unknowable in development. I'd probably um make sure to have good backups before the new dev starts.