Lessons Learned From the Software Industry
VS Code started reporting this error recently any time I pressed CMD+N (New File):
command '-workbench.action.files.newUntitledFile' not found
The root cause of this issue was that the Dart language plugin needed to be reloaded. I assume this might also be the case for any other language plugin that is installed. If shortcut keys stop working, try checking your plugins and reloading them.
🔎 Looking for an Android Job?
I just wanted to give everyone a quick heads up – Caster.IO is now managing AndroidJobs.IO 🎉 – the #1 independent Android Job board.
With Caster.IO‘s adoption of the site, we’ve redesigned it and made it super easy for you to find and post jobs to our job board.
If you’re looking for a new position in the industry or if you’re looking to hire someone to join your team – we’re here to help. Each job posting will be sent out to our email list as well as included in our #AndroidDev Digest newsletter for 4 weeks at no additional cost.
We already have a number of great jobs posted to the site, by companies such as:
Including AndroidJobs.IO into Caster.IO’s portfolio of sites inches Caster.IO closer to my goal of it being your #1 destination for Android content, news, and education.
Check out the Jobs on AndroidJobs.IO
As always, if you have any questions or concerns, drop me a line below 👇
TLDR; The Fix: Plug your Pixel 2 into a USB 2.0 port, not a USB 3.0 port.
If your Pixel 2 device will not connect to ADB (Android Debug Bridge) with a USB cord then you might want to check the port that it is plugged into. I’m using a USB-C to USB-A cable, in fact, I even went and bought new cables because I assumed my problem was with cables – nope.
Some Pixel 2’s will not connect over USB 3.0, you will need to connect it to a USB 2.0 port. In my case, I decided to use a USB 2.0 hub that I had lying around. As soon as I connected the phone to a USB hub (which was, in turn, connected to my MacBook Pro), everything was golden.
I connected it, the Pixel 2 device recognized I was connected and prompted me to trust the computer. At that point I was able to see the device with adb devices from the command line and from within Android Studio. 🎉
This issue was reported in December 2017 and unfortunately it has not been fixed. I say unfortunately because if I were a new developer learning to code Android, this could be a supremely frustrating experience and could deter myself (and many people) away from Android development. First time experience is key.
I hope that helps!
Happy coding.
Writing in Markdown is probably one of the best experiences you can have for a technical writer for a few simple reasons –
If you’re using markdown to write your blog posts, you can post them to your WordPress site if you’re using the wp-markdown plugin you can easily get code to show up in a formatted code block by simply adding the back ticks or tab spacing.
This is great, except the default theme is not the greatest.
Under the hood, wp-markdown uses Google code-prettify, which allows theming. Thankfully, many kind folks have created themes for code-prettify and shared them online. I found one I really liked here. The problem was, how do I get this theme applied to the wp-markdown plugin? It’s quite simple …
Important Note: Before modifying any theme or plugin files it is recommended that you back your site up just in case you completely bork something.
To update the theme you want to use on WP Markdown, simply go to your WordPress dashboard and then go to Plugins > Editor.
From there, you’ll select the WP Markdown plugin and then you’ll click Select.
Next, you’ll open the css folder on the right hand side and select the prettify.css file.
Once this file is open in the editor, you’ll take the theme CSS that you want to use (I grabbed one from here and modified it to my needs) and you’ll replace the prettify.css file contents with the file contents of the theme of your liking. Then you’ll click Update File.
Thats it, your site should now be using the new code-prettify theme that you specified!
You may have noticed that WordPress has this nice little warning:
Warning: Making changes to active plugins is not recommended.
This is true, you need to be sure what you’re doing here. If you edit the wrong file, you could completely host your WordPress installation. Be careful here.
If you have any caching plugins, be sure to purge the cache. This can also happen if you run on sites like WP Engine, be sure to flush their cache. Also, if you’re running on a CDN, make sure the CDN file is updated. I had a CDN enabled and it was not picking it up until I flushed everything and reseeded it.
When you you update a plugin, a new version of the plugin is downloaded and installed over the top of the old one (more or less). This can, and usually will wipe out any changes you made to your plugin (Ala what we did in this post). To make life easier, save the css that you put into the prettify.css file into an online site like gist.github.com so that when you do update your plugin you can easily repeat these steps with your updated theme (because the plugin update will wipe out your updates).
Enjoy!
I get it. Your application (mobile app or web app) doesn’t have tests and … well … you’re scared anytime you make changes.
Why? … well … because you’re not sure if you broke anything when you commit that code.
I encounter this a lot in the realm of software consulting.
The more tests you have, the more confident you will be that you didn’t screw anything up.
Yeah, Ok, I get it, but what if I don’t have any tests, where do I start?
Great question.
A launch test is a functional test that runs on your continuous functional server (or even your local machine if you don’t have CI yet) that confirms that the application you just compiled/etc will actually start and you can hit the home screen/home page of the app.
Simply check that your home screen text is showing as you would expect it to show and that certain key values are present. Simple. Done.
Hold up … but I know I didn’t break my home page. Why should I test it? Why is this important?
You said you didn’t have any tests. Are you sure you’re sure you didn’t break it?
Thought so, probably not.
The reason why this is important is that you may have made a change to the dependency injection code that uses reflection that does something at runtime that would only be exposed when the app is run.
What would happen if you didn’t catch that in development?
đź’ĄBOOM! CRASH! đź’Ą
Exactly.
Furthermore what this first functional test does is give you a starting point. It gives you a jump off point. It’s your first test of many.
Yes, it might hit production servers. Ok, when you test manually you probably were hitting production servers too. Yikes. It is what it is.
The key thing to remember here is that you now have a test covering you to ensure your app launches.
Ultimately the next thing you should be testing is your most used screens:
Once you get some tests around these screens (do they load, do they work when interacted with) then you can refactor.
That’s the key takeaway here. Tests give you the confidence to do work that otherwise might be overly stressful and risky because you’re not sure what you’re breaking.
Functional (and integration) tests are the best place to start because they’re true end-to-end tests and they mimic what the end user is going to see and this is important because …
Nothing else matters more than the end user experience.
If the end user sees a screen that’s broken, gets a crash, or sees incorrect data they’re not going to be happy and they won’t give two cents that your app is powered by AI with advanced machine learning to render results from a globally decentralized blockchain network running on Ethereum.
User’s don’t care about your cool tech stack if your app doesn’t work.
To the user, if the app doesn’t work, it’s garbage.
… and …. well … at that point, let the 1-star reviews come flooding in.
So … if you don’t have any tests, start with some functional tests and then you can refactor with confidence and then and only then should you introduce more testing mythologies into your app.
PS: If your app is an Android app, quickly set up an Espresso launch test with the Espresso Test Recorder. Sam Edwards has a great course on it here.