Category: Development
You are viewing all posts from this category, beginning with the most recent.
Introducing Silvertooth
| 
| 
|
I'm excited to take the wraps off of a development tool that we've been using internally for years. In the spirit of the holidays, we've decided to release it as a free gift to the community – Silvertooth, a Bluetooth wireless scanner that allows you to connect to, and inspect devices in your physical vicinity.
We created Silvertooth to help diagnose and debug our IOT and wireless apps, and it has saved us countless hours trying to hunt down difficult to find protocol/hardware bugs. Built on our open source UUBluetooth framework, Silvertooth is our gift to the community to install and use, free of charge.
One of the unique aspects of Silverpine is that we are a unique blend of technical prowess and skillful design capabilities. We built one of the first mobile credentialing apps, we have created multiple IOT apps, and we are experts in mobile app development in general. On the design front, we have been building software for small screens since before the iPhone even existed, and we understand the nuances of bringing a brand or design model forward into the mobile ecosystem. With Silvertooth, we are giving an opportunity to see both of these in action.
If this is an area you work in, we hope you find it useful. Happy holidays!
Rowing With the AI Current
There is a lot of hyperbole around AI at the moment, and it can be difficult to sort through the noise. Part of the problem, I think, is that much of the focus has (incorrectly) been on generative AI. People get stuck arguing about how realistic an image is, how good a particular LLM is in generating pictures of human hand, or how creepy deep fake videos are. This is largely a distraction – there's so much more going on than just generative AI! These are amazing times because with the right approach, AI can be leveraged to imagine new products that could not have been built even just a few years ago.
But while it's a radical advancement in technology, it's still just another tool in the toolbox for creating amazing products. At Silverpine, we have embraced it internally as a productivity multiplier in our development process, and a few of our current projects have a significant AI component. However, this doesn't make us an AI company, and in fact, I would argue that a company that claims to be an "AI company" is very likely selling snake oil.
That being said, companies that fail to understand and embrace AI expose themselves to considerable existential risk. The power of AI is a generational leap forward in human productivity. Just like the smart phone, the Internet and the electrical grid, the arrival of AI has the potential to unlock another level in human output. And just like those other technologies, there come with it inherent dangers. However, I firmly believe that in the long run, the benefits will greatly outweigh the costs – there's no sticking the genie back into the bottle.
It feels like there are new discoveries and announcements nearly every day. Personally, I'm positively giddy thinking about the things that can be done that previously seemed impossible. And while the unknown can sometimes feel scary, we will do best if we lean into them. What can we make now? What can we do now? I'm excited to find out. Just remember that your ship will travel much further if you row with the current!
Tools For a Distributed Software Agency - 2024
Originally inspired by Justin Williams, I try to spend some time at the end of every year reviewing and describing the various tools and software that we use at Silverpine. This is now my fifth year doing this type of retrospective. If you're interested in the previous posts, you can find them here:
We are a mobile-first software design and development agency, and as such our tools generally fall into three general buckets:
- Communication
- Development and Design
- Operations
I try to be as exhaustive as I can in my list, but every year I seem to forget something. If you don't see something that you would expect to see, please reach out. Also, if you have suggestions for alternative tools, I'd love to hear about them. We are constantly trying to refine our toolset.
Communication
Slack - As a fully remote organization, I don't know how we would operate without Slack. Our usage has continued to grow as we now regularly use Huddles, Notes and Canvas in addition to the core messaging. With almost 10 years of searchable Silverpine chat history, Slack is an absolutely indispensable part of our day-to-day operation.
Zoom - There are lots of options for video-conferencing software - from Teams to Google Meet to WebEx. We have used the vast majority of them and repeatedly, Zoom is still slightly better than the competition. However, I will note that our usage has drastically fallen as our usage of Slack Huddles has sky-rocketed. That being said, whenever I need to chat with someone outside of the company, I still turn to Zoom.
Google Workspace - We regularly use Docs, Sheets, Drive and Gmail. They work and are fine. There's nothing particularly special about them, although I do find that Drive doesn't work nearly as seamlessly as Dropbox.
Dropbox - We barely use Dropbox, but we have enough legacy documents that we have a couple old accounts still hanging around. If Dropbox had better pricing for small teams, we would probably use it over Google Drive, but Dropbox is pricey enough that we can live with the deficiencies of Drive for our team sharing.
Keynote - One tool that I use frequently (and that I seem to have neglected mentioning in past years) is Apple's Keynote. Nearly every presentation I create is done in this tool. It's just so much easier to use than Powerpoint.
Operations
Harvest - Many people use Harvest for time-tracking and while it's a great tool for that function, we use it for invoicing clients. It has a pretty great search and history function. My only wish is that it had better visual reporting capabilities.
Gusto - We have been using Gusto for payroll for years. In general, we still are big proponents of it, but their service has fallen off quite a bit the past couple years. We pay for their Plus level service, and even with an elevated service level, it still takes too many calls and emails with an offshore representative to get things resolved.
Quickbooks - We use Quickbooks, and since the CPA propped-up monopoly shows no signs of cracking, you probably should use it too.
Adobe Acrobat Pro - Adobe gets a lot of heat for some of their licensing decisions, but using Acrobat Pro to handle our document digitization hasn't been a difficult choice. Whenever we need to add signatures to paper documents and create digital versions of them, Acrobat just works.
Excel - As mentioned previously, we pay for the Google Workspace suite of products. And while I do use Google Sheets frequently, I still prefer the offline capable, familiar warm embrace of Excel. You might disagree, but to me, it is the embodiment of what a spreadsheet application should be.
Development and design
Xcode - If you write iOS or Mac software (as we do) using Xcode is really the only option. I know that some people have hybrid setups with alternative text editors, and while I won't judge those people, I really do think it's just easier to use Xcode. However, I do wish Apple would focus a bit on stability and performance instead of adding features.
Android Studio - I don't personally do Android development, but I know that our Android engineers use Android Studio. It's free so I don't mind, and it sounds like there's not really a better alternative.
VS Code - It is remarkable how good VS Code is given that it's free and offered by Microsoft. Our engineers use either this or Nova for any non-native projects.
Nova - I've used Nova a few times and it's fairly intuitive and has a large, well supported plug-in architecture to a diverse set of development environments. It's a very viable alternative to VS Code, and while it isn't free like VS Code, it does have some advantages. Panic makes great products.
Tower - We don't mandate a Git client at all, but we do provide a "default" for the team. Tower is always improving and the fact that it's cross platform really seals the deal for us.
GitHub - Every now and then I am forced to use Bitbucket, and it makes me appreciate GitHub. We've been slowly moving more of our CI infrastructure into GitHub Actions as well.
Figma - The current reigning champion of wire framing and design is Figma. I was quite relieved when the Adobe acquisition fell through.
OmniGraffle - I don't love OmniGraffle, however, if you need a Visio-equivalent tool for the Mac, there aren't really many options. The interface is a little off-putting and difficult to learn, but it does what I need it to do. I really wish Microsoft would create a Mac version of Visio though.
BBEdit - I don't personally use BBEdit, but a huge number of our team does. Primarily, they use it for large file manipulation and inspection as well as just a general quick "scratchpad" for writing and note taking. It's tremendous how long BBEdit has been around and that it's still a daily driver for so many people.
Evergreen.ink
I'm super excited to announce the public beta period for Evergreen.ink, our interactive fiction authoring tool. If you already are familiar with interactive fiction and/or Evergreen.ink, feel free to just head on over and start creating! If you want to know more, read on!
Interactive fiction is content that falls somewhere between a game and a story. It reads like a novel, but the reader gets to help determine the flow and content. One of the most common forms of interactive fiction is "choice-based interactive fiction." If you've ever read any of the classic Choose Your Own Adventure books, then you've read interactive fiction. This is the foundation of what we have built with Evergreen.ink.
We have already launched a series of titles that are built using the platform. While working on the content for these titles, we realized that the authoring system we were building is something special, and that it has utility outside of our internal needs. We decided to open up the platform more broadly. The user experience of Evergreen.ink is incredibly intuitive, but it belies the powerful Sapling scripting engine that hides just under the surface. Authors can write either narrative content, or they can dip into the more advanced features and add truly intelligent behavior to their stories.
The platform is targeted toward choice-based interactive fiction intended for reading on mobile devices. This is a recognition that the mobile reading experience is one that will reach the broadest audience, and as a result, the default playback and reading experience is tailored specifically for small-screen devices.
We have begun work on a native viewer as well that we plan to launch it in Q1 2024 in the Apple App Store and Google Play. Our end goal is to help authors easily write interactive fiction stories and to eventually provide a platform for monetization. Already, content authored in Evergreen.ink can be played back in a web browser or via uploading to Itch.io where authors can monetize their stories.
Interactive fiction can sometimes seem like a novelty, but as a media platform, it has a huge amount of untapped potential. We hope that Evergreen.ink allows authors the freedom to stretch their imaginations, and we look forward to seeing what people create. This is just the beginning of the journey for the platform; we have a lengthy product roadmap and are excited about where we are headed.
Ok, that's a lot of words, but since we're talking about an interactive platform, how about an example? One of the first titles we created was a short take on The Picture of Dorian Gray by Oscar Wilde. It's a quick, simple example of what Evergreen.ink can do. You can check it out here: Mystery at Gray Manor.
We hope that Evergreen.ink is useful to creatives that are interested in discovering a new platform. We hope that the tool fades into the background as authors simply do what they do best: create.
(If you're interested in finding out more, please don't hesitate to contact me or to join the Evergreen.ink Discord.)
Apple's Native Apps Trojan Horse
Apple announced SwiftUI at WWDC 2019 and like a lot of people, I mostly ignored it because I knew that it would need some time to mature before it would be ready to use in production software. I also wasn't sure if it would "stick" in terms of long term, viability. However, after another year of development, it's clear that Apple has made a commitment to it. The newly announced Widgets and App Clips as well as enhancements to WatchOS definitely push developers hard towards SwiftUI.
SwiftUI appears to be Apple's answer to the React programming movement, and given the similarity of SwiftUI to React, I expect a lot of the response will be positive. However, I believe this to be a bit of a Trojan Horse in relation to cross-platform development. As I mentioned earlier, apps that want to use some of the newer technologies, like Widgets, have no choice but to use SwiftUI. For an app that's written natively in Swift, this will be easy. Apps written in cross-platform environments will have to work a lot harder.
Eventually, Widgets and App Clips will become expected functionality for many apps, and while most cross-platform solutions already support mixing native code with non-native code, the level of complexity of supporting these will essentially require developers to be fluent in multiple languages and multiple development environments. I'm very curious to see how these cross-platform development communities respond and adapt to this change because over time this will erode one of their key advantages.
Finishing Software Is Hard
For the last couple years, my 15 year old son has been slowly building a gaming computer for himself, piece by piece. For his final computer component, I agreed to purchase it for him if he could accomplish one very specific task. Namely, I wanted him to recreate an iOS app that I had written years ago as I was learning iOS development. He has a natural inclination to programming and has dabbled with many different coding challenges so he figured that it wouldn’t be too difficult to do.
For the most part he was correct. He started working on it last summer and was able to quickly get a large chunk of the functionality working. He was fairly excited about it, but then I started explaining some of the other things he needed to do before submitting it: an about screen, a splash screen, cleaning up the layout for the various phone screen sizes, etc. What happened next was predictable. His enthusiasm waned and he pretty much stopped working on it. He filled his time with other things and his almost-finished computer sat staring at him in his room.
On more than a few occasions he tried to negotiate a smaller task, but I kept explaining to him that the point of the exercise wasn’t to see if he could program (I knew he could.) But rather, could he finish something hard and complex. As any seasoned developer knows, finishing software is difficult and always takes longer than you expect. It’s also not a skill that people learn in school. It’s something that can only come with time and experience.
During this period of extreme social distancing, our kids haven’t had school and the transition was so sudden that teachers didn’t have time to create assignments or lesson plans for students while they are out. As a result, our kids find themselves on some bizarro extended spring break where they can’t see anyone. The boredom is real and families are trying to figure out what to do with themselves. The silver-lining for me is that I have a little more time to spend with my family and I finally convinced my son to sit down and finish his app.
The amazing thing is that as soon as he finished and submitted to the App Store, he found a sort of “second wind” where he wants to keep working on the app and add more features and functionality. To me, this is the magical reward of finishing software. When you finish something you feel such a sense of accomplishment and get a boost of energy and enthusiasm. It’s a feeling that I love and is difficult to explain to someone that hasn’t gone through a tough finishing exercise. I’m very happy that I was able to share this with my son.
Oh, and if you’re curious about the app he built, you can find it here:
https://apps.apple.com/us/app/doodle-dots/id324487932?ls=1
Tools for a Distributed Software Agency
One of the things that I am most proud of is that Silverpine is a 100% distributed company. Often when people find out that we are fully remote, they will ask curiously about what tools we use to work together. This is completely understandable because the importance of having the right tool set is magnified for remote companies. We understand this innately and as such we are constantly evaluating our software stack. The following list represents the software that powers our business. (I have intentionally omitted some of the lower level development tools like Xcode and Android Studio.) The list is broken into four primary classifications: communication, development, project execution, and finance.
Communication
Slack
Before Slack, we used a hodge lodge of messaging tools like AIM, Google Chat and even old school SMS. It was horrible. Slack is the single most important tool that we use to communicate with each other and with our clients. All of our employees and contractors use it extensively every day, and even though I think that there should be some middle ground in their pricing between the paid and the pro plans, I can't imagine trying to work remotely without it.Webex
Let me just preface this by clarifying that I think that every single conference calling platform is terrible. I have used them all. From Zoom.io to Google Hangouts to AT&T Connect, they are just barely workable. Besides the all too common call drops they also all seem to suffer from ridiculous installation processes and byzantine user interfaces (Does this yellow button state mean my microphone is on mute or can they hear me?)That being said, we have been using Webex for a very long time; not because it is good, but because it is better than the alternatives. And for our enterprise clients, it is somewhat of a known entity so we seem to spend less time per call doing the “can you hear me” dance. I wouldn’t say that I recommend Webex. It’s just what we use.
Dropbox Pro
We have been using Dropbox on personal plans for quite a while, but we recently decided to standardize on Dropbox Pro for file sharing. All of our projects have quite a bit of documentation, graphical assets and other large files that aren't well suited for source control tools. Dropbox allows us to create per project file drops that we can easily access as well as share with other people when appropriate. We almost switched to Box.com because their pro plans have unlimited storage but ultimately decided it would be less transitional headache to just upgrade our existing Dropbox plans.G Suite
We have been using Google for our email and calendar services for so long that our silverpinesoftware.com domain is still functioning under the original beta operating agreement. If G Suite disappeared I honestly wouldn't even know where to start looking for a replacement. File this one under "it just works."Development
InVision
One of Silverpine's guiding design principles is that every user interface needs to have a beautiful "feel" to it, and that you simply can't judge the feel of an app until you can hold it in your hand and interact with it. Because of this philosophy, we have refined our development process over time to rely heavily on InVision to prototype the UI and UX of our apps before we ever even start writing code. The amount of time and pain it saves both us and our clients cannot be overstated. If you design for mobile, you really should be using InVision or something like it.GitHub
If you write software, you should be using a source control platform. If you need a source control platform you should be using GitHub. If you're using something else, I'm sure you have a reason for it, but it's probably not a very good reason. (All of our projects use GitHub repositories so when they changed their pricing model to be per user rather than per repository, it made our lives a lot easer.)Azure DevOps
This one might surprise some people, but a couple years ago we transitioned to what is now known as Microsoft Azure DevOps for our automated build system and have been using it ever since. Prior to Azure DevOps we had used a variety of tools including TestFlight (bought by Apple), Fabric (bought by Twitter, then bought by Google), and BuddyBuild (ran out of money). Due to intense consolidation in that particular sector, we were frequently having to retroactively change our toolset which was both time consuming and costly. A friend of mine who works on the Microsoft tools team encouraged us to give Azure DevOps a try, and we have been extremely happy with that decision. Azure DevOps supports both iOS and Android, is massively configurable, has 24/7 support and most importantly, is backed by one of the largest companies in the world so it won't be disappearing any time soon. If you need an automated build system and haven't taken a look at Azure, I highly recommend at least kicking its tires.Project Execution
Basecamp
For many years, we wandered in the desert of project management, largely piggybacking on whatever project management tools our clients happened to be using at the time. As such, we have used everything from Jira to Asana to Microsoft Excel to track projects and tasks. However, in the past year we have implemented Basecamp as our standard internal project tracking tool. One of the things I like best about Basecamp is that it has clearly been thoughtfully designed. Not only is it powerful, but its design somehow works to ensure that it doesn't become overly burdensome in the same way that other similarly complex tools do.Lighthouse
If there was one piece of web software that I would invest internal Silverpine resources on, it would be a lightweight bug tracking tool. There just aren't many platforms out there that can strike a balance of utility and ease of use that errs on the side of ease of use. For now, Lighthouse foots the bill for us in that regard, however, I'm not sure how much longer it will be around. There hasn't been any significant development done on it in the 6+ years that we've been using it, so I'm not sure I would necessarily recommend it. That being said, it does what we need bug tracking software to do, and it does it well, and I haven't found a replacement. If you have any personal favorites, please let me know.Finance
Blinksale
Silverpine is a services business and sending invoices to our customers is literally how we are able to make money. Blinksale is the tool we use to send those invoices and look like we are professionals in the process. While it isn't a complex tool, it expertly does what we need it to do: send and track professional looking invoices. If you send invoices to clients, you really should be using a tool like Blinksale because people can tell when you don't.Quickbooks
Nobody really loves Intuit. They have created not one, but two near monopolies with TurboTax and Quickbooks. However, if you run a business, you need to track your finances in a way that your CPA can help you with your taxes at the end of the year, and if you tell your CPA that you use anything other than Quickbooks, they will not be happy with you and they will very likely take longer to do your taxes which means you will end up with a higher bill from them. That is the reality of Quickbooks and that is why we use it.Gusto
If you have employees or sub-contractors that you need to pay, you really should be using Gusto. The folks at Gusto are wizards when it comes to dealing with payroll taxes and W-9's and a great deal more things that I simply don't have to worry about because we use their service. Not only is the Gusto platform super easy to use, but their customer service team is actually pro-active in notifying us of upcoming tax law changes that might affect us. I am continually in awe of how great Gusto is and cannot say enough good things about them.
The Trouble With Cross Posting
Recently, I setup a microblog (http://jonhays.me) to supplement my interactions on Twitter, Facebook and Instagram. After several conversations with my friend Manton, I decided that I would setup a new WordPress site and use that as the content “repository” and use cross-posting tools to distribute out to Twitter, Facebook and Instagram.
There are several reasons for doing this, but my primary motivations are:
- I want to spend less time on the individual social media platforms.
- I want to own my content and have better control over it.
One of my high level requirements is that I wanted to be able to post to my microblog from my phone. Another of my requirements is that I wanted to be able to post entries both with and without images. Of course the third requirement that I mentioned above is that it needs to cross-post to Twitter, Facebook and Instagram.
Naively, I just assumed I could use the WordPress app and setup a few IFTTT triggers and be done with it. As you can guess, it’s not quite as simple as that.
Let’s tackle cross-posting of images first: what should be posted to Instagram for a blog entry with no image? With multiple images?
Realizing that simply posting from WordPress wasn’t going to work, my first instinct was to modify my workflow so that if I wanted to post an image, I would post from Instagram and use an IFTTT action to then cross-post the image to my microblog which would then cross-post to Facebook and Twitter.
Unfortunately, using this method is like playing a game of telephone with social media and the end result looks like this on Facebook:
Several of my friends replied after seeing these asking if my computer got “hacked.”
Images aren’t the only troublesome area either. Take for instance cross-posting of text posts larger than 140 characters to Twitter. It turns out that IFTTT is actually quite terrible about handling these as well:
Simply truncating the text without a link back to the original post is the worst kind of tease and also not acceptable. What a good cross-post tool should do is truncate at word boundaries and provide a link back to the original post. IFTTT is simply not up to the task for this.
In fact, as it turns out, IFTTT is actually quite terrible for cross-posting to just about every platform. I am investigating other alternatives at the moment but as of right now, I am still stuck with those terrible Facebook cross posts, and I have no way to post directly on the microblog and have the ones with images get cross-posted to Instagram.
Fortunately, there are smart people working on these problems! I’m using a beta tool to do the cross-posting to Twitter. The beta tool actually works quite well and I’ve been trying to convince the author to expand to include Facebook as well, but he’s reluctant to add more features at the moment because he’s trying to launch.
With so much out of control negativity and lack of author control on Twitter and Facebook, it feels like there is an opening for something like micro-blogs to augment existing platforms in a positive way. And while I don’t think Twitter or Facebook are going anywhere, I believe micro-blogs can help fill the gap for content creators that are conscientious about their craft.
I’m still exploring other avenues for cross-posting and I’ll try to post updates as I find them either here or on the microblog, but it feels like this is a viable, mostly untapped market.
Thanks for the Memory
How much memory can an app allocate on an iPad 1? It seems like a trivial question. The original iPad has been in circulation for over 3 years now and developers have written thousands of apps, many of which are memory intensive. Given this, one would expect that this limit has been well documented and should show up easily in search results. As I found out recently, this is not the case.
A few weeks ago, I needed to revisit memory consumption on an app running on an iPad 1, and I became very curious about the answer to this question. After searching various sites I was mostly coming up empty. To my surprise, it was quite difficult to find this documented anywhere. Apple's own documentation is of course great reading for any developer but remains mum on memory budgets. Perhaps the best documentation I could find was this Stack Overflow post, but it didn't seem to be definitive and as with all Stack Overflow posts, caveat emptor.
One thing that I did find sprinkled around the various posts on the topic was a link to Jan Ilavsky's tool that he wrote to measure on a device the various points when an app receives memory warnings and then ultimately crashes due to insufficient memory. Here's a shot of it in action. Using Jan's tool, I decided that perhaps I should help contribute to the collective information of the Internet by running some tests and documenting them.
So as not to boil the ocean, I decided to analyze only the iPad family of devices. My test devices included: a first generation iPad, a second generation iPad, a third generation iPad and an iPad Mini. All of the devices were upgraded to the latest version of iOS that supported them*. My procedure was to force quit all apps on the device before running the test app and then to run the test a minimum of 10 times on each device. I would then throw out the low and the high and graph the results. I found to be both interesting and somewhat predictable:
[caption id="attachment_58" align="aligncenter" width="300"]
First Generation iPad (iOS 5.1.1) [/caption][caption id="attachment_59" align="aligncenter" width="300"]
Second Generation iPad (iOS 6.1.3)[/caption][caption id="attachment_93" align="aligncenter" width="300"]
iPad 3 (iOS 6.1.3) [/caption][caption id="attachment_61" align="aligncenter" width="300"]
iPad Mini (iOS 6.1.3)[/caption]One of the more interesting things that jumped out at me is the fact that Apple seems to take memory optimization seriously, and that their approach appears to not be a one size fits all method for the different devices. Notice how on the second generation iPad and the iPad Mini the OS continues to optimize in order to allow the app more room in which to operate. Contrast that with the first and third generation iPads which appears to have a flat, non optimizing algorithm. If indeed memory optimization does have a certain amount of device specificity to it, it would appear that Apple put less time into optimizing these iPads.
This of course makes sense as the first iPad was a previously non-existant category, and the third generation was the first iPad with retina display. You have to imagine that it was a pretty massive undertaking to introduce the retina concept on an OS, toolchain and device level. I don't think any engineer alive would be surprised if the schedule became tight on these projects. The point here however, is that Apple does indeed pay attention to the details and that permeates all the way down to device specific memory optimizations. Developers should of course never become reliant on the presence of these optimizing algorithms but the fact that Apple puts that much attention into it is impressive.
So, back to my original question of how much memory you can allocate on an iPad 1. Drumroll please. Based on my results, I would say that for the iPad family of devices the following are the maximum allocations that can be performed by an app:
First Generation iPad: 160 MB
Second Generation iPad: 250 MB**
Third Generation iPad: 515 MB
iPad Mini: 275 MB***
Now, I wouldn't be doing my civic duty if I didn't point out that these numbers include things that are entirely out of your control such as core graphics objects. The test application is the most plain vanilla of apps so the minute you start making anything interesting this number will begin to be impacted. In the end, there is simply no replacement for good old fashioned testing and optimizing so keep that in mind as you're setting out to make the next Angry Birds. I do find this helpful however because it is useful to know and be aware of what my overall ceiling is so that I can spend time optimizing the things that need optimizing and spend the rest of the time building features.