At UA1 Labs, over the past 2-3 years we have been busy building out a software suite we call FireStudio. FireStudio, and its accompanying libraries (FireTest, FireBug, FireDi, FireSQL), have all been actively developed for one reason. To enable web users to secure their privacy on the web and services on the web. With the focus of technology on cloud, big data, and machine learning, we have a growing concern of what that means for the average user of the web and their privacy.
To achieve data privacy we want to make it simple enough for each person to own their data and be able to distribute it via their personal API.
Background
Early on in my career, I recognized an issue with the web. Using any web services would force me to give up my privacy. Everything I do on the web is being tracked, analyzed, and used to target a reaction from me. Most of the time, I’m being targeting to make a purchase, and sometimes I’m targeted to react with an action. Major tech companies have gotten so good at targeting reactions and behaviors, they can even predict, within a certain accuracy, what your reaction will be based on the collection of data they have about you and other people. I don’t want to live in that world.
History of FireStudio
Ever since I’ve learned to code, I’ve had a continuation of a dream to build out a system that would allow users of the web to control how their data is used. There has been many variations and implementations of this idea over the past 15 years I’ve been developing.
Zoose
For me, it all started with Zoose. My very first attempt at building out a PHP application. It was a CMS that used the concept of editable content to allow users to edit titles/images/content directly within the webpage they were viewing. At the time, it felt like working in word. The framework itself featured a flat file database as I wasn’t sure what MySQL was or how to use it. So I built my own. http://buildzoose.com was created with a forum and I attempted to open source it. The framework ended up being used in several client’s production servers and did well for a bit. One client still uses it today to run their listing website.
Z20 (or Zoose 2.0)
After learning about some design patterns and becoming more mature with my coding practices, I realized how hard Zoose was to maintain. So I decided to start rebuilding Zoose on another code base. This time I would centralize my approach around Dependency Injection. Z20 was a short lived iteration. As a framework built around DI isn’t really a framework at all. Z20 would eventually become Ulfberht, which would then turn into FireDi. I built many different projects with this framework including a Twitter bot that would allow users to tweet pixel information at it that would place that pixel on a canvas in an experiment we called “Social Art” (https://twitter.com/tweetcreate).
This framework became more about making money and less about driving innovation around the cause of data privacy on the web. For me, everything I’ve built, the end goal was to build tools that would allow for a decentralized web that would still allow people to share info, photos, likes, etc. After realizing that things weren’t going in the direction I wanted them to, I decided to pivot yet again and refocus my efforts towards pure data privacy.
FireStudio
The idea for FireStudio was born. I decided I would take everything I’ve learned and focus all of my energy on solving the problem I had set out to solve 10 years earlier. I mapped out everything I would need to solve this problem and would just start building. I needed debug tools, testing automation tools, a way to connect to a database, security tools. Everything I would need I listed.
FireDB
One of the first things I set my effort on was to build a database that would allow users to secure data. I wanted a NoSQL database that would allow users to store any type of data that they wanted to. But I didn’t want users to have to deal with, “well how do I setup a MongoDB instance to connect to my application?” Sure there is cloud solutions for stuff like this, but that stuff is hard. Especially for the average web user.
This would become a 4 month journey to build my own flat file database system that users could just download and use. Now archived https://github.com/joshualjohnson/firedb.
FireSQL
Along the way of building out FireDB, I found that the database itself wasn’t very performant after you got to more than 2 million records within a collection. All of the features I wanted were there, but I wanted the database itself to be more performant than it was. So, I took all that I had learned in FireDB and applied it to FireSQL. A solution that would take a SQL database and make it into a NoSQL database. I settled on this as a solution because most LAMP services provide MySQL out of the box.
FireBug
FireBug came along because I needed to debug FireSQL/FireDB as I was building it. I wanted the more efficient way to debug and I needed more than just var_dump. I wanted to know how long queries were taking, performance of code, etc. So I created FireBug as a way to have a debug panel that could have all of the things I needed.
By the way, FireBug’s name was a total accident and was never meant to step on the heals of FireBug the Firefox extension. More about that here https://ua1.us/updates/firebug/why-did-the-firebug-php-debug-panel-project-copy-its-name-from-the-dev-tools-built-for-firefox/
FireTest
FireTest came along because when I was building out FireSQL/FireDB, I needed a way to test multiple scenarios as I was developing. The scope grew too big for me to manually test all of its functionality every time I went to add new functionality. So I build out a test automation tool that allowed me to verify everything was still working as expected.
FireDi
As mentioned before, this originally came from Z20.
Finally FireStudio
It took me a little under 2 years to write all of the code I would need to create all of the components of FireStudio. But yet I still have no app for a user to run that will allow them to share their data on the web without sacrificing privacy! I envision FireStudio to be an application that runs on a server. Which will allow a user to host their own data via a restful API. One that they own and control who can access it. I would like to see apps created that could be used to access individual user api’s. Rather than having to host a user’s data, I would like to see these apps simply consume their data.
I started to build out a stand alone application, but recently decided to ship this as a WordPress plugin.
Why Put FireStudio In WordPress Plugin?
For me, the answer is simple. The vision for WordPress and the vision for FireStudio are pretty much inline. WordPress wants to make it possible for the world to share information. FireStudio wants to make it possible to share data.
The post The Vision for FireStudio and Our Other UA1 Labs’ PHP “Fire” Libraries appeared first on UA1 Labs.
Top comments (1)
So compared to Query monitor what is the difference?