Server-Side Swift: New Hero in Web Town

There’s a new hero in the world of web applications, services, and microservices: Server-Side Swift is making serious waves across the industry. At Beezwax, it’s changing how we approach and solve many typical, long-standing coding challenges.

Continue reading “Server-Side Swift: New Hero in Web Town”

Agile Where You Least Expect It

One of the things that I always think about is how linked Agile Methodologies are to Software development. But what concerns me the most is that sometimes it is believed that using Scrum in other contexts is impossible or that it is not even considered.

Continue reading “Agile Where You Least Expect It”

JavaScript for FileMaker with bBox

In 2017, we released several new versions of bBox plugin. In the spirit of yearly retrospective, let’s highlight perhaps the most exciting new bBox feature: JavaScript for FileMaker. The new JavaScript for FileMaker functions in bBox are great for heavy duty JSON processing tasks, repurposing JavaScript code for use in FileMaker, or other computation intensive processing. Here’s a recap…

Continue reading “JavaScript for FileMaker with bBox”

Large d3.js Application Development

“Code that belongs”. This is the mantra, the quest, of Beezwax Senior Developer Ryan Simms; which he discusses in this ten-part article on building a large-scale web application using d3.js. How to write code that fits the context intrinsically. The article focuses on specific techniques with the data visualization library, d3.js. But the lessons are broad. How do you make something fit — in ways that make it feel like it belongs?

Continue reading “Large d3.js Application Development”

Writing a Markdown Compiler – Part 2

Hello, and welcome to the second part of the Markdown Compiler series! In case you’ve missed it, here is the first part.

In this part we’ll talk about the second step in compiling: Parsing – also known as Syntactic Analysis. This part has a bit more theory, so it might take some time to digest. Sip some coffee, relax, take yout time, and as long as you don’t rush it you’ll find it’s not hard at all 🙂

Continue reading “Writing a Markdown Compiler – Part 2”

Getting Started with REST and cURL using FileMaker’s Data API

If you are FileMaker developer, but new to the notion of web APIs and web development in general, then you might take on a kind of deer-in-the-headlights look when confronted with FileMaker Server 16’s new Data API, aka “REST API”. Fear Not! It really is simpler and more straightforward than you might expect. I like to take the attitude that no skill is difficult, only unfamiliar. With study and repetitive exposure and practice, any skill can be mastered.

Continue reading “Getting Started with REST and cURL using FileMaker’s Data API”

FileMaker & Tableau | A Match Made in Data Heaven!

It’s here and I feel like I have to tell the whole world… which is what I am doing! Now that FileMaker 16 is officially announced, there are lots of exciting things to talk about that are now possible. I think one of the most powerful new features that have been introduced in version 16 is the capability to integrate with other applications or services. There is so much to talk about what now becomes possible with FileMaker and other services/applications.

Continue reading “FileMaker & Tableau | A Match Made in Data Heaven!”

Maximizing Diversity to Bridge The Tech Gap

Work To Be Done: Bridging The Tech Gap

If you follow tech industry news I am sure you’ve read and heard about the need for greater diversity in the industry. While the discussion began with a focus on women and people of color, diversity in hiring also includes people with disabilities, parents in need of flexible scheduling, gender diversity and people from diverse socio-economic backgrounds.

Continue reading “Maximizing Diversity to Bridge The Tech Gap”

The Human Resource

20 years in, a founding Bee reflects

Julian Nadel is president and founder of Beezwax. He’s celebrating the 20th Anniversary of Beezwax with this, his premier Beezwax Blog post.

Many CEOs of tech consultancies spend their time on the frontlines of code or clients.

Continue reading “The Human Resource”

Logging PSoS Activity: Episode III – Return of the JSON

In looking back at our initial approach to logging FileMaker PSoS (Perform Script on Server) activity, I reflect back on a number of times where this has been extremely helpful. If you have come to rely on the benefits of PSoS then you also know some of its challenges — one of the biggest is debugging and monitoring how long sessions take.

Since FileMaker 16 introduced JSON, in new systems we’ve switched over to using JSON as the main way of exchanging data for parameters. Because we also use PSoS in new systems, we updated our method for PSoS Logging and this blog entry talks about the changes we made there and also restates the usefulness of this log.

So as mentioned, we update it to no longer require our custom functions for parameter passing. Those date back all the way to the six fried rice methods. After more than a decade of fine use, we finally retired them. Now in any new systems we build, we pass parameters using JSON.

It never ceases to amaze me how we can always improve our code with new ways of thinking.

There is one custom function that is at the heart of the way this works, I think it is very forward-thinking in its architecture.

Credit Steve Senft-Herrera (aka “Steve”) of Beezwax for redefining things using this approach. And Arnold Kegebein for technical review and corrections.

LogPsosParameter ( StartOrEnd )

NOTE: We store our token in a local variable scoped to the current script. This means we can set it at the start of the script, and still retrieve it at the end of the same script. The custom function builds the JSON object at the time it is called.

The first time called with Start, it builds the ID for the script. When it is called at the end it can then use that variable to locate and update the PSoS log record. The nice enhancement that Steve made in the custom function is that it doesn’t have to return the PSoS ID it is working with — the ID is in a variable that both the script and custom function have access to that save variable. One would think that defines the laws of variable scope, but no, it works and it is great. And Steve is a genius!

Here is what the PSoS script looks like in action:

Paired scripts

There is another design choice that we make when relying on PSoS and that is to have scripts work in pairs. So, we have a local script that might make sure that everything is OK to run the script on server. For example, often times we’ll do validation on the date before it gets set to the server. If everything is good then we’ll call the script via PSoS. Sometimes we’ll want to wait for the result sometimes we don’t. In either case, I find it helpful to separate them out into 2 parts.

Some developers like to have the patter of a single script being self-calling. I find that too confusing when you are trying to debug it. Just my preference!

NOTE: There are limits to how many concurrent PSoS sessions you can have. That setting can be found on the Sever Admin –> Database Server –> FileMaker Clients.

Maximum Simultaneous Script Sessions:  ###

It allows you to set this number to a very high number, but good rule of thumb is to not set it more than double the number of cores that you have.

Exploring the log

Once wired up and you want to explore the log, here is an example of what it looks like. There are 2 important columns of information: RS and RE. RS means the total number of scripts running at the start of this script, and RE means the total number of scripts running PSoS at the time this current script terminated. So, in the example below you’ll see a section primary in green. What this tells you is that you maybe have a runaway script.

What it can be helpful at telling us is how long these scripts have been running concurrently.

For this log to work it needs to have 3 custom functions, 1 table, 2 layouts ( one for the PSoS Log and one for the PSoS report ), and 1 script. Let’s look at how this works. The other thing that we recommend for PSoS logging to work reliably, would be to follow a pattern called Single Pass Loop. What this pattern allows you to do is guarantee that your script has one entry point and one exit point. This is important for PSoS logging: if you can guarantee that you only have one exit, then you can always call the terminating part for doing PSoS reliably. Including the calls for PSoS Logging, here is what the basic structure of the script would look like.

Implementing this into your solution is done with a few easy steps:

  1. Copy the 3 custom functions
  2. Copy the PSOoS table ( the default layout will be referenced by the script )
  3. Create a new layout named “Report PSoS”
  4. Copy the PSoS script folder ( it should copy over the folder and the scripts )
  5. You are ready to start integrating PSoS Logging into your solution!

Enjoy! And please let us know if you have any questions or need any help.

Demo File


Account: Admin
Password: PSoS

Product Ownership: From 0 to 60 in Three Meetings

At the Agile Open Conference in Northern California, I was inspired by the Open Space forum to share and learn from those gathered about product ownership. As a software project manager, I’m tasked with helping define, facilitate and participate in product ownership roles. One of the biggest challenges I face is also part of the thrill in working with a consultancy: there are many active projects and each one is unique. So in this session, I asked "How could we define, assess and begin executing the product ownership role in three meetings?"
Continue reading “Product Ownership: From 0 to 60 in Three Meetings”

FileMaker Server 16 Gotcha: Get ( SystemDrive ) and Friends

FileMaker 16 has been out for several months, however we wanted to call attention to a change that can effect your application’s use of server side scripting. Recently, we upgraded a client project to FileMaker Server 16, and found that critical functionality had mysteriously broken. After a bit of sleuthing and gnashing of teeth, we found that changes to the output of Get(SystemDrive), when executed server-side (PSOS or via a scheduled script), was the culprit.

Continue reading “FileMaker Server 16 Gotcha: Get ( SystemDrive ) and Friends”

Creating Your Own SSL Certificates For FileMaker

Typically, you buy an SSL certificate for a server from a SSL vendor. However, some companies may decide that they want to issue their own SSL certificates. Often this is because the domain is only used internally, and most vendors don’t easily allow (if at all) the signing of server certificates for non-public domains. Additionally, issuing your own certificates can remove complications caused by the certificate verification process used by most vendors, and there are no fees needed for each certificate.

Continue reading “Creating Your Own SSL Certificates For FileMaker”

LOgiCATOR Part 3: Ready, Set, Integrate…Into Your FileMaker Apps

We’re thrilled to announce the official, “integration-ready” version of LOgiCATOR. LOgiCATOR is a modular search interface for FileMaker that can be easily integrated into new or existing solutions. It’s designed to help users locate data with logical precision, via a powerful yet intuitive interface for searching across FileMaker tables. This article includes a download link for the module and demo file, describes what’s changed since the preview version (a lot), and explains how to integrate LOgiCATOR into your FileMaker solutions.

Visit the LOgiCATOR page at Beezwax. Continue reading “LOgiCATOR Part 3: Ready, Set, Integrate…Into Your FileMaker Apps”

1 2 3 18