Quick little script to read the length of a string:
echo "Enter some text"
krypted April 9th, 2018
Posted In: Mac OS X, Mac OS X Server, Programming
bash, read the length of a string, Shell Script
My latest Huffington Post article, called 20 Constants In Software Development
is up. It starts out like this:
There are so many things I wish people had told me when I was in school, or earlier in my career. Things that aren’t variable between organizations you work with, or even teams you work in. So I thought I’d jot a few down of these for software development teams (if only to prove that no, despite what product managers say, you aren’t crazy). So here goes:
A project will never have enough people to build all the features you want. Period.
Less features means fewer defects.
As a software project nears completion the amount of work remaining rises in proportion to how many hacks and shortcuts you took.
krypted December 11th, 2017
Posted In: Articles and Books, Programming
Apple, scope creep, software development, testing
There’s a great site out there called spellcheck.net
that will check your bash scripts to verify that they are syntactically correct and offer some tips on fixing issues you may encounter. In the example below, I single quoted at the end of a quoted string, and… error
Hat tip to Daniel MacLaughlin for posting this site.
krypted December 14th, 2016
Posted In: Programming, Ubuntu
Apple developers in growing development teams invariably need a continuous integration system. This automates the build, analysis, and testing solution for software development using Xcode. macOS Server has an Xcode service, capable of integrating your developer account with git, providing many of the options required to build a continuous integration system.
Before you configure the Xcode service that can take committed code and then test and build your software, you’ll need an Apple developer account. The Xcode service then links git to a developer account and runs automations, referred to as bots, in Xcode. Therefore, you’ll also need to have Xcode installed on the computer running the Xcode service. Bots are then managed and reported on using a web app that the Server app runs.
Once the pre-requisites are met, open the Server app and click on the Xcode service.
Click on the Choose Xcode button.
When prompted, browse to the version of Xcode you have installed on the server.
Configure the user account to use for the service.
The service will then require you to login. Do so when prompted.
This enables the user account, which you will then need to login as.
You’ll see a new user environment. Use fast user switching to then switch back to your other account. Xcode will require access to the Accessibility framework to run unit tests. Click on Request Access to provide the rights to Xcode to do so. Once access has been granted to Xcode, you’ll see the version indicated in the Build Using field.
Next, click on Add Team, in order to identify the correct team from your Apple Developer account that will have access to the Xcode service.
When prompted, select the team from your Apple Developer account that you wish to provide access to the server, note that you need to be a team agent or an administrator of the developer organization.
Click on the Repositories tab. Here, you will define repositories for your Xcode projects. Click on the Repository Access button to define what protocols git should be accessible via.
At the Repository Access screen, select HTTPS or SSH. Click OK.
Click the Edit Repository Creators button. At the Repository Access screen, add any groups of users that should have access to create new git repositories. Once all of the appropriate users or groups have been added, click on OK.
Select your repository again, and click on the HTTPS Access button to provide access via HTTPS. Once saved, double-click on the repository again to see the uri for each type of access. And that’s it.
Next, you’ll want to add a repository to the Xcode app. To do so, open Xcode and then use the Source Control menu to select Check Out. From there, you’ll get a Check Out screen.
At the Check Out screen, enter the uniform the repository screen, shown in the previous step of this article and click on the Next button. Next, you’ll need to create bots to automate your build process.
krypted October 8th, 2016
Posted In: Mac OS X Server, Programming
Apple, cvs, MAC, macos, Repository, sierra, svn, Xcode
There is a little tool in OS X called opendiff. This command can be used to bring up a quick and dirty graphical view of changes in a file. For example, if you run opendiff followed by two file names, you’ll see what’s different in the two files and what’s the same:
opendiff test test1
The result then looks as follows.
Note that in the above screenshot, a and b are in white lines and the others are grey, as those are consistent in the two files and the c has been removed and replaced with the four lines on the left. In larger files, this is pretty useful as it provides quick insight into what is different between two files, like what changed in a script between two different versions.
krypted August 27th, 2016
Posted In: Mac OS X, Mac OS X Server, Programming
built-in, changes, MAC, programmatically, scripts, track changes between files
Dropping network connections can be incredibly frustrating. And finding the source can be a challenge. Over the years, I’ve found a number of troubleshooting methods, but the intermittent drop can be the worse to troubleshoot around. When this happens, I’ve occasionally resorted to scripting around failures, and dumping information into a log file to find the issue. For example, you may find that when a network connection fails, you have a very strong signal somewhere, or that you have a very weak signal on all networks.
I’ve found there are three pretty simple commands to test joining/unjoining, and using networks (beyond the standard pings or port scans on hosts). The first is the airport command, along with –disassociate. This just unjoins all networks:
sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport --disassociate
The second is a quick scan. Here, I’ve grep’d out the network I’m after (aka SSIDofNetwork – a very likely wireless network name), but when looking for environmental issues, you might choose to parse this into a csv and output all networks:
sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -s | grep SSIDofNetwork
Finally, you can join a network. You might have to escape out special characters in a password and it’s never wise to put a password into a script, etc. But, quick and dirty, this will join that SSIDofNetwork network:
sudo networksetup -setairportnetwork en0 "SSIDofNetwork" mysecretpassword
Anyway, loop it, invoke it however you invoke it, etc. Hope this helps someone, and if you have other tricks you’ve found helpful, feel free to throw them in the ‘ole comments!
How Users Feel About Intermittent Networking Issues
krypted August 26th, 2016
Posted In: Mac OS X, Mac OS X Server, Mac Security, Network Infrastructure, Programming
airport, Apple, bash, Join Network, scripting, testing dropped connections, unjoin network, wi-fi
Forgot to save the source code of those AppleScripts in a place you can find it again before you compiled? Quick and dirty, provided you didn’t save it as ReadOnly, you can grab the source of an AppleScript using osadecompile. Just feed it the app (not the applet or the main.scpt btw), as I do with /Users/charlesedge/Documents/mycompiledapp.app below:
krypted August 21st, 2016
Posted In: Mac OS X, Mac OS X Server, Programming
Published 5 Lessons App Developers Can Learn From Pokémon Go
with App Developer Magazine. Really more focused around the business of app development and release, and a quick read. Hope you enjoy!
krypted August 19th, 2016
Posted In: Product Management, Programming
apps, development, pokemon, software
Next Page »
Every development organization has tech debt. Modern development projects have gotten so large and complex that there are now dozens of libraries, frameworks, and services implemented in a modern solution. Additionally, there are always new techniques, new modules, new frameworks, new skills, and new perspectives. Applications are now ecosystems, constantly evolving, and our perspectives about them must evolve as well.
Yes, a burn down chart looks better when you pay down the debt. Yes, security flaws can force you to pay down technical debt. Yes, most developers always want to fix all the things, including impending dead technology. Modern solutions have many stakeholders. The modern roadmap has to include benefits for existing customers, senior management, the people you send into the field, and net-new customers, coming in based on new features that need to get implemented.
You can’t implement new features that help to retain customers and acquire new customers if you are always paying down technical debt. Here are 10 good ways to tell if you need to re-evaluate plans to pay down some technical debt:
- There’s a new version coming out. Let’s face it, there’s always a new version just around the corner. But a release can be imminent. Take into account the timeline of a new release and choose where to spend your precious development capital, being careful of frameworks, libraries, and services that have a new version about to come out.
- A version is too new. A cooling off period is necessary with any new technology. Otherwise, you’re learning about all the bugs and limitations of a new solution in real-time. The larger a development organization, the longer it takes to develop the institutional assets required to perform a large-scale effort to implement new technology. And the greater the risk if you go the wrong direction. For example, if you are already updating production applications to Angular 2, are you sure that’s a good idea?
- You have to retrain an entire team. Retooling an entire scrum team, or larger efforts require you to rethink how you approach various problems, and can require hundreds of hours of training for engineers. When you are looking at larger projects, consider how much time the new tools will save versus the cost to bring in experts to train your staff, as well as the hours required to actually do the work.
- You can’t hire talent that know the new technology. This is a huge red flag. Maybe you can’t hire someone to help you out because the supply is tapped, maybe you’re trying to implement a framework that’s too new, maybe the library is too old, or maybe it just plain sucks. Either way, if you can’t find engineers willing or able to implement, rethink the whole situation.
- The cost of doing the project is greater than the cost of other efforts if you do not do the project. Not paying down technical debt accrues interest. That interest can build up over time. But what if it doesn’t? What if the new project makes others more complicated, or doesn’t simplify others? Consider the impact to other initiatives, both positively and negatively when prioritizing your technical debt; especially smaller projects.
- You have to replace other parts of the solution to make the new parts work. We’ve all been there. You have 4 libraries that don’t work with the new framework. If you start the implementation of new technology, you’ll want to check on each interconnected framework and library prior to beginning to do so, if only so you can properly estimate the time required.
- Solutions come with new licensing requirements. As noted, most modern projects are ecosystems of dozens of open and closed source libraries (if not more). Many teams now keep a document, or entire database, of the types of licensing used for each of the building blocks that make up the stack of a given application. Each time you update to a new version, you’ll want to first validate that you aren’t entering into an entirely new set of licensing terms.
- Initial tests go poorly. OK, so you don’t need to scrap a project just because projects where you attempt to scratch the surface go poorly. I like to start with some small wins, stick my toes in the water, and then re-evaluate timelines based on how the initial tests go. You want to get some nice momentum on the burn down chart before you head into deeper waters when doing larger development projects.
- You can’t compartmentalize the new technology. Let’s say you’re implementing React Native into an application. You already have a user interface that users have been using for, in some cases, several years. Can you implement React on a screen-by-screen basis, or given the architecture of your existing app, will you have to do the whole thing at once? If you can’t compartmentalize the new technology, is it really right for you?
- You are spending more to pay down technical debt than on new features. Mature products often get you into a place where you’re spending more to keep up with your existing code base than you spend to implement new features in your tools. When you get into this kind of scenario, you definitely need to stop accruing technical debt; however, you should re-evaluate whether a much larger rewrite would be more appropriate than fixing little things here and there.
- Your goal can be accomplished in another way. Let’s say you have an API, and you never bothered to ship documentation on using the API. This is actually pretty common. There are tools like HATEOAS (https://spring.io/understanding/HATEOAS) that can allow you to basically self-document the API within the API. Is it better to do that or publish a quick PDF on using the API? Either way, you need the PDF. Most of us would, if time allowed, prefer to go the HATEOAS route; however, again, we have to be judicious with our time.
Ultimately, we all have a limited pool of resources. And as our solutions grow, the amount of effort required to update parts of the code will grow as well. A lot of these tips involve taking into account the resources required to update the building blocks of a larger application, or project or timing. There’s no doubt that the longer you incur the debt on each of your initiatives, the more interest each incurs. But sometimes, it’s important to keep a larger picture in mind.
With limited resources, there is no right answer when it comes to keeping your code modern. You don’t want to accrue too much technical debt. Otherwise code will become unwieldy and developers will run away from your organization when they realize just how much of a hurdle it will be to update your code. But you have to implement new technology in order to keep from keeping up with 30+ year old FORTRAN code in 2016. Next time product management and developers compete for prioritization, check these tips, and see if you’re going down the FORTRAN route, or keeping too modern; hopefully it’s somewhere in the middle.
krypted August 11th, 2016
Posted In: Articles and Books, Product Management, Programming
reasons not to pay down tech debt