Tag: php

Posted on

Validation in Laravel Artisan commands

One of the things I like most about using Laravel is that most everything I’ve needed to do so far is pretty intuitive.  If I try to code up something the way I think it’s supposed to work, usually it does.

I’ve been working on adding some new Artisan commands to my equipment database to handle some of the back-end administrative tasks that I’d normally have to fire up a browser for.

Naturally I want to validate the input.  Laravel’s got some really nice validation rules that would be nice to use in my new artisan commands.  The documentation covers doing validation on incoming HTTP requests, but isn’t clear on whether the Validator can be used more generically.

Looking at the documentation for manually creating validators, a Validator instance takes two arrays: an array with the data to be validated, and an array containing the validation rules.

It seemed like I could use the Validator facade pretty much anywhere as long as I had arrays of data and validation rules.  In my artisan commands, I added a use statement for the Validator facade, 

use Illuminate\Support\Facades\Validator;

and the rest mostly followed the manual validator creation docs.

$validator = Validator::make($model->toArray(), [
  // validation rules
]);

if ($validator->fails()) {
  // show validation errors and exit
}
else {
  // do stuff with validated data
}

Much happiness ensued when I tested things out and saw that the validations were working just like I thought they should.

Posted on

RadDB: Storing and viewing test data

Development on my equipment database has slowed down a bit partly because of being busy at work and partly because the database files on my home computer keep getting corrupted for some reason and I haven’t bothered to figure out why or fix it yet.

The equipment tracking part does pretty much everything I need now (still a few things to take care of), so my latest efforts have been on trying to get the test data locked in my spreadsheets into the database.

I started off using the PhpSpreadsheet package (which is still under development), but I found a lot of what was in the documentation wouldn’t work. I ended up going to the older PHPExcel package instead. Using this made it relatively easy to create some Laravel Artisan commands that pick out the test data from my spreadsheets and stick them into the database. Now I can batch add data to the database using a simple shell script. One problem with the current commands is that they won’t work with older version of my spreadsheets yet because the locations of some of the data has changed over time. Not sure I’m too worried about that yet. They also don’t handle problems very gracefully yet. Something to work on later perhaps.

The DB schema for the test data is still being worked on, but I think I’ve got something that will let me pick out data for an individual survey, as well as show a time series from a specific test for a given machine.

Current works in progress are views to display the test data. I’ve got a few done, but still have a bunch more to do.

I love how easy doing all of this has been with Laravel.

Posted on

RadDB: Radiology Equipment Tracker

Long ago, when I first started at MUSC, I inherited a stack of binders that contained all the reports for the imaging equipment that needed to be tested annually.

There was a total of about 50-55 or so  units, and for the first couple of years, I’d find a few units here and there that weren’t in the binders, but still needed annual testing. By the time I was reasonably sure I had all of them accounted for, there were around 70 units.

For a while, I could keep track of all the units and when they needed testing in my head for the most part. I knew I was going to need a better system to keep track of things though.

Around mid-2001, I came up with what seemed to me to be a reasonable database schema to store everything in, and cobbled together a bunch of PHP scripts (back when PHP was used mostly for templating and generating dynamic HTML pages) to serve as the front end.

It worked pretty nicely, but adding anything new was a fair bit of work and my scripts didn’t really interact with each other. On my list for a long time was to rewrite the whole thing as a more self-contained web application that would be easier to maintain and enhance. Work and life kept me busy, and my scripts worked well enough that there wasn’t a whole lot of motivation to revamp everything (“If it ain’t broke…”).

Fast forward 15 years later to 2016. With my equipment inventory at around 175 units, people discovering my project, and asking for new functionality, there was significantly more motivation to rewrite everything. I spent a few months in early 2016 checking out various PHP frameworks before settling on Laravel.

The RadDB project kicked off around May of 2016. With most of my programming time happening during short windows between testing equipment, and after work, I managed to replicate about 80% of the functionality of my original hodge podge of scripts by the end of 2016. With the start of the new year and a new round of testing, I decided that RadDB was ready for production, so I set it up on my desktop at work and released it into the wild.

I use it to:

  • keep an inventory the imaging units and x-ray tubes I need to lay hands on each year
  • add/edit new imaging units and tubes
  • generate reports on the types of machines, where they’re located, and who made them
  • track when they were tested
  • track any problems I might have found during testing
  • tell me what machines
    • still need to be tested
    • which ones have been scheduled for testing
    • which ones have already been tested
  • store test reports and service reports
  • track calibration dates for my test equipment

Still a lot of work that needs to be done on the project. Most of the other features I want to implement involve learning other parts of Laravel (authentication, services, unit testing) so I don’t think those will be too hard to get done.

I’ve really enjoyed working on this rewrite, and learning how to use Laravel in the process. It’s a pretty cool framework and easy to learn. For the most part, I can imagine what I want, think about how to do it and then code it up without having to do a lot of mental gymnastics and translating to get it to work. I’m looking forward to doing other projects in Laravel.

 

Posted on

Climbing the Laravel learning curve

After checking out several different PHP frameworks, I settled on using Laravel for redoing the x-ray equipment tracker that I use at work. It’s been a TODO project on my list for quite a while now and for the past couple of months, I’ve been studying the Laravel docs, writing up the redesign of my project and trying to put together some code.

I’ve managed to learn how to use Laravel enough to implement some simple tasks such as displaying lists of the x-ray units stored in the database. It’s actually been surprisingly easy, and I haven’t really had to write a whole lot of code. For the simple tasks that I’ve implemented so far, Laravel has done most of the heavy lifting. I just write the code to say what I want and how to display it, and Laravel does the rest.

So far most of the work I’ve had to do was in redoing the database schema to match the conventions used by Laravel’s Eloquent ORM. That mostly involved renaming tables and indexes, and trying to figure how to define the relationships in the model files.

Still have lots of learning and work to do, but I’m making progress. Baby steps.

Posted on

Reworking an old project

Now that I have my equipment database project living comfortably over at code.google.com, it’s time to think about how I want to rewrite it and what I want to do it with. The new version of whatever I end up creating will live over at github, since that’s what all the cool kids seem to be using these days.

Since PHP is what I know, it’s the most likely candidate for this new version (although I’m open to using something else). Leaning heavily towards using some kind of framework for it, although I haven’t picked one out yet.

I had a thought that I could maybe use Drupal to take care of the front end stuff with the back end being handled by modules that I would create. Each piece of equipment would be a Drupal ‘node’ and modules could be used to create the reports as ‘views’. I need to dig into Drupal dev more to see if something like this would be viable.

Lots of possibilities to choose from. All of them will force me to expand my rudimentary programming skills earn more skill levels in programming.