Welcome back, in Part 1 I started talking about what it’s been like for me to start learning FileMaker. Today I talk about about what my impressions are having had some experience, what the future might hold, and what I’m expecting to find along the way.
I’m now three months down the line learning the ropes with FileMaker 12 and it’s now become a lot easier to use. The tools are familiar, and although I don’t hugely like FQL, FileMaker Query Language, I can understand and use it. I’ve done some basic work for clients in this time and, weirdly, I’ve started testing a lot. It’s something I knew came with the territory of developing having been around it before and knowing the development cycle, but never really saw myself doing it. It’s not hardcore testing in terms of spending solid weeks putting the system through it’s paces, and more a developer peer testing, but still to be three months in and being trusted with not missing the obvious and/or being able to point out where the system is generally not fit for purpose is a nice feeling.
FileMaker on the whole isn’t as scary as I thought it would have been to work with from scratch, but what is getting to me now is working with systems that already exist. It feels harder to understand how a system works than I am traditionally used to, though this is most likely down to the way that everything’s laid out. For instance, working with a Unix system everything is about script stages, and it’s like a breadcrumb trail, following it from file location to file location reading through scripts. However debugging a FileMaker system is more like following a breadcrumb trail that’s been left in three different locations and they cross over half way through. The ability to cause scripts to happen effectively whenever you want to them is great, but trying to figure out what’s happening is harder. All I can really say about this is thank you to the person who realised that a script step debugger would be useful.
It’s been an interesting month; first time out to a client site, being trusted to solve their problems for them as well as looking to the future and certification. That’s a daunting idea; Certification in FileMaker. Those of you that have done it already might be thinking “What’s so daunting about certification?”. Well imagine it from my point of view. Having effectively just come out of the education system where you get to see test papers from previous years and know what you’re expecting to see come judgement day, the concept of having no idea what you’re going to be walking into, and hearing different things from several people about how the test is set out, is a pretty daunting feeling. Sure, it’s just a test that at the end of the day doesn’t really matter if I screw up on for the first time but still there’s a pressure that makes you still not want that feeling of disbelief if yourself after. Imagine it as being told you’re going to sky dive this month at some point. Just the fact you’ve never done it before is going to make you apprehensive of what is about to happen to you. Granted, if something goes wrong in this test I’m not going to hit the ground hard, but at the same time that gut wrenching apprehension is really distracting.
So far so good I guess. There is definitely something I have realised though; I really dislike developing on someone else’s platform and solution. Unlike developing on a website or adding to a SQL based system you have to understand a lot more about the system that already exists. Because of the way that the stacking system of scripts runs you can’t just go throwing things into a script and testing them. It can take a long time for me personally to understand what is happening in a system and how I go about changing fields and layouts to be able to achieve what I want to without breaking other things. There are ways that we make it easier for other developers working on a system like using a naming convention for all of our field names so that you don’t have to try and guess what it relates to. With other systems, like an SQL solution, everything is very procedural. We work through each procedure one after another without breaking to go to a different procedure, of course there are exceptions to this and complications but typically we don’t call multiple procedures within another procedure. Where as with FileMaker it’s like having a procedure and having to take into account other procedures within that procedure. Layout script triggers, field script triggers, timed scripts, button scripts. All of these add to the stack, which just makes everything more confusing when taking into consideration a domino effect of changes to a system.
Interface design is something I’d like to see change in the industry and a community in general, and this will be something I talk about more next time, because although we get functional systems that can showcase some talent and knowledge in the system design and what the system can do. It’s frustrating that as an industry we want functionality with very little style instead of taking time over how your solution looks as well. I’d like to see some really nice graphic design along side showing that we take care of how we make a solution look.
That finishes this weeks blog, stay tuned in the coming weeks for other blogs from us here at Linear Blue as well as more on how I’m finding FileMaker as a development tool…