Sync Hacks is a column dedicated to exploring new applications for BitTorrent Sync, as built by users like you. BitTorrent Sync is a free, unlimited, secure file-syncing app. (And now, it’s even more mobile.) If you’ve got an epic Sync idea, use-case or how-to, shoot us an email at sync[at]bittorrent.com.
In this week’s Sync Hacks: Mikko Haapoja, Director of Creative Technology at Jam3 (a digital production/design agency in Toronto, Canada) shares how his shop uses BitTorrent Sync to create an asset management system that appeases both designers and developers.
Asset management in an agency setting can be a real pain. You may have many exported images and videos that go through multiple iterations until the designer is fully happy with it. You need a system that is easy enough for a designer to use but robust enough for a developer’s needs.
Previously at Jam3, we were using Git for our asset management. This always felt slightly wrong. Our repositories would get massive and in the end, we really only cared about the final “approved” assets. Developers hated having to download massive bloated repos, and designers hated having to learn a system like Git that felt too “developery.” Alarm bells would ring when a designer would have a conflict while merging.
Needless to say, Git for asset management phase didn’t last long.
One of the nice things about Jam3 is that we’re able to try new processes and tools on projects easily. We work in small teams, which generally consist of a producer, a designer or two, and between two to five developers. The project is lead by the Triforce: a Producer, Lead Designer, and Lead Developer. During a project, the three will make decisions about new tools and processes they may want to include. At the end of the project, they are also required to evaluate what worked, what didn’t and what could be improved. This gives Jam3 the opportunity to stay on the cutting edge.
After using GIT for asset management for a little while, we realized it would not cut it in the long run. We needed a system that would be much easier for designers to use but still robust enough for developers. We decided to experiment with a system where we had a centralized asset server. Designers would be able to simply drop files into a folder on the server using Finder or Explorer. We then wrote a Grunt script, which would RSync files from the centralized server to the developers. This way, the developer never had to download bulky repos, and the designers still had the ease of use they were used to.
This system worked quite well; however, there were some quirks. If a developer required making a small asset change, they’d have to save the file to the centralized server and then pull the assets from the server via RSync/Grunt. This was the only easy way to ensure that everyone on the project had the same assets. In the end, the only main difference between having just a centralized server and developers manually downloading files from the server was that it was being automated by Grunt. One very scary thing about a system like this is that if someone for instance, deletes a file from the centralized server, everyone can potentially lose that file. There is some assurance that there is some redundancy where one of the users “may” have the file since they haven’t “synced” with the server; however, it’s obviously not fool proof.
Enter Resilio Sync. We began experimenting with Sync while working on Royal Canadian Mint’s Heart of the Arctic. This project had a huge bulk of images and videos. Some people at Jam3 had been using Sync personally at home to back up and store images/videos from their phones. It worked fantastically there, so why not bring it to work? Sync gave designers the ease of use where they could simply drop assets into a folder and for developers, the process was even more automated than Grunt. You would have the designer’s files almost instantly, without having to worry about it. To ensure that assets changing did not affect the application’s logic (sometimes this may happen with game-like experiences), we added in an extra step where Grunt would simply copy the files from the Sync folder to the asset folder (which was for development). This gives developers the control the previous systems had, meanwhile completely circumventing external/slow servers.
It was neat to see the thought go from “I’m using this cool piece of software at home” to “how can I bring this to work?” Where as with other asset management systems we simply iterated or abandoned it, with Sync we began to think “what else can we use this for?” Some teams have began to experiment with a concept similar to what Twitter Murder is with Sync, where you actually push sites to a development server using Sync. This worked great, but it’s something we’re still experimenting with.
The next thing we’d like to begin to experiment with is the Sync developer API, and we believe this will open even more doors for this great piece of software.