I started working my first job as a full time professional software developer recently, and frequently find myself having to search through a seemingly enormous codebase to try and find things. This function is defined here but… where in this 50,000+ lines of code is it actually called and executed?

At first I tried using Azure DevOps built-in search functionality to search through our repository, but this really just hasn’t been working. Often times I find myself searching for a function after looking at it’s definition, and the Azure DevOps search bar will not be able to find where the function is actually called.

So here is the solution I’ve stumbled upon, which I’m sure industry vets all know about already: grep

That’s it! That’s the answer to your woes if you are having trouble searching through a large codebase. Simply fire up a terminal window on your Mac, navigate to your project’s directory, and enter the following magical command:

$ cd ~/yourSuperSweetProjectDirectory

$ grep -r -i someTextYouAreLookingFor *

Quick little tutorial here, mostly for my own personal reference, on how to restore your local working directory to match a remote master branch. Take this scenario for instance, you’re working on a project for work, maybe as a junior developer working on your first professional project, and you make a bunch of changes to your working directory that you want to throw away, and restore your project to match the remote master branch. Here are your four magic commands:

$ git checkout master

$ git fetch origin

$ git reset --hard origin/master

$ git clean -df

Similarly, if you want your local working directory running on your personal computer to match a different remote branch other than master, you can run something like:

$ git checkout users/myusername/myfeaturebranch

$ git fetch origin

$ git reset --hard origin/users/myusername/myfeaturebranch

$ git clean -df

Hopefully someone will find this blog post extremely helpful. Tonight I purchased an Amazon Fire TV Stick with the intention of building a cool new React app for the Fire Stick. My hacking session started off well, but I soon ran into an awful bug where my Fire Stick would continually display nothing but a black screen for my React app when using the Web App Tester.

Well after two hours of struggling with this issue, I discovered the solution to this problem: You cannot use a white background color when developing HTML5 apps for Fire TV Stick. All I had to do to get my app to start working was change the background color to purple!

When starting a new project developers tend to start with a blank canvas and a little black text, but this will not work on the Fire TV Stick. So if you find yourself running into a similar problem where you just can’t get your Fire Stick to display your Hosted HTML5 app using the Web App Tester, try changing your background color to something other than white.

I’ve been struggling the past couple of days experimenting with the Google Cast SDK in an attempt to create a new mobile app where users can “stumble upon” new YouTube videos and cast them to their televisions using Chromecast. However, I’ve run into a couple of big problems and would like to share what I’ve learned:

1. The YouTube Player API for mobile apps isn’t compatible with the Google Cast SDK. If you want to show a YouTube video in a mobile app, the YouTube Player API works great. If you want to cast a video from your mobile app to a Chromecast, the Google Cast SDK works great as long as the video is hosted on your own servers. But if you want to cast a YouTube video from your mobile app using the Google Cast SDK + YouTube Player API, you are out of luck!
2. Chromecast does play nicely however with anything you want to cast from a web browser running on a desktop or laptop computer. I didn’t run into any problems trying to “cast a tab” using YouTube embeds from my desktop or laptop computer.
3. The last lesson I learned from experimenting with the Google Cast SDK is that Custom Receiver applications don’t seem to work. I’m sure someone out there has been able to get a Custom Receiver to work, but I personally was not. I am assuming that most people who are building apps which are capable of casting video to Chromecasts are using Styled Media Receivers. I did quite a bit of experimentation over the past few days and never ran into trouble using Styled Media Receivers (receiver apps hosted by Google), but I absolutely couldn’t get a Custom Receiver to work at all.

So there you have it! You can’t cast YouTube videos embedded in mobile apps. You can easily cast YouTube videos embedded in websites on desktop and laptop computers. And Custom Receivers for Chromecast don’t work, use Styled Media Receivers instead.

Privacy Policy

Your privacy is important to me. It is  my (Christopher Pedersen) policy to respect your privacy regarding any information I may collect from you on my app, Surf with Swayze.

I only ask for personal information when we truly need it to provide a service to you. I collect it by fair and lawful means, with your knowledge and consent. I also let you know why I am collecting it and how it will be used.

I only retain collected information for as long as necessary to provide you with your requested service. What data I store, I will protect within commercially acceptable means to prevent loss and theft, as well as unauthorized access, disclosure, copying, use or modification.
I don’t share any personally identifying information publicly or with third-parties, except when required to by law.

My app may link to external sites that I do not operate. Please be aware that I have no control over the content and practices of these sites, and cannot accept responsibility or liability for their respective privacy policies.

You are free to refuse our request for your personal information, with the understanding that I may be unable to provide you with some of your desired services.

Your continued use of my app will be regarded as acceptance of our practices around privacy and personal information. If you have any questions about how I handle user data and personal information, feel free to contact me (chris@topherpedersen.com).

This policy is effective as of 4 August 2020.

Terms of Service

1. Terms

By accessing the app “Surf with Swayze,” you are agreeing to be bound by these terms of service, all applicable laws and regulations, and agree that you are responsible for compliance with any applicable local laws. If you do not agree with any of these terms, you are prohibited from using or accessing this site. The materials contained on the Surf with Swayze app are protected by applicable copyright and trademark law.

2. Use License

1. Permission is granted to temporarily download one copy of the materials (information or software) on Christopher Pedersen’s app for personal, non-commercial transitory viewing only. This is the grant of a license, not a transfer of title, and under this license you may not:
   1. modify or copy the materials;
   2. use the materials for any commercial purpose, or for any public display (commercial or non-commercial);
   3. attempt to decompile or reverse engineer any software contained on Christopher Pedersen’s app;
   4. remove any copyright or other proprietary notations from the materials; or
   5. transfer the materials to another person or “mirror” the materials on any other server.
2. This license shall automatically terminate if you violate any of these restrictions and may be terminated by Christopher Pedersen at any time. Upon terminating your viewing of these materials or upon the termination of this license, you must destroy any downloaded materials in your possession whether in electronic or printed format.

3. Disclaimer

1. The materials on Christopher Pedersen’s app are provided on an ‘as is’ basis. Christopher Pedersen makes no warranties, expressed or implied, and hereby disclaims and negates all other warranties including, without limitation, implied warranties or conditions of merchantability, fitness for a particular purpose, or non-infringement of intellectual property or other violation of rights.
2. Further, Christopher Pedersen does not warrant or make any representations concerning the accuracy, likely results, or reliability of the use of the materials on its app or otherwise relating to such materials or on any sites linked to this site.

4. Limitations

In no event shall Christopher Pedersen or its suppliers be liable for any damages (including, without limitation, damages for loss of data or profit, or due to business interruption) arising out of the use or inability to use the materials on Christopher Pedersen’s app, even if Christopher Pedersen or a Christopher Pedersen authorized representative has been notified orally or in writing of the possibility of such damage. Because some jurisdictions do not allow limitations on implied warranties, or limitations of liability for consequential or incidental damages, these limitations may not apply to you.

5. Accuracy of materials

The materials appearing on Christopher Pedersen’s app could include technical, typographical, or photographic errors. Christopher Pedersen does not warrant that any of the materials on its website are accurate, complete or current. Christopher Pedersen may make changes to the materials contained on its app at any time without notice. However Christopher Pedersen does not make any commitment to update the materials.

6. Links

Christopher Pedersen has not reviewed all of the sites linked to its app and is not responsible for the contents of any such linked site. The inclusion of any link does not imply endorsement by Christopher Pedersen of the site. Use of any such linked app is at the user’s own risk.

7. Modifications

Christopher Pedersen may revise these terms of service for its app at any time without notice. By using this app you are agreeing to be bound by the then current version of these terms of service.

8. Governing Law

These terms and conditions are governed by and construed in accordance with the laws of TX and you irrevocably submit to the exclusive jurisdiction of the courts in that State or location.

Having some trouble using Certbot to install an SSL certificate for your website? Getting hit with an error message that looks something like?:

Failed authorization procedure. yourdomain.com (http-01): urn:ietf:params:acme:error:dns :: No valid IP addresses found for surfwithswayze.xyz

IMPORTANT NOTES:

The following errors were reported by the server:

Domain: yourdomain.com
Type: None
Detail: No valid IP addresses found for surfwithswayze.xyz

Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.

Okay, so here’s what’s probably going on: You just bought your domain name, set your nameservers, uploaded a landing page to your server etc., then wham! Certbot just doesn’t want to add that little https to your URL. The issue may be that your newly registered domain name hasn’t propagated through the internet’s DNS registry yet so Certbot is having a hard time finding the corresponding IP Address for your new domain.

The solution? Just give GoDaddy or whoever else you used to register your domain a little more time update everything and try running Certbot again.

If you’d like to test this hypothesis out, try visiting your new domain through Google Chrome AND Mozilla Firefox AND/OR Apple Safari. I found that while Google Chrome could not find my new domain, Firefox found the new domain easily and displayed my placeholder landing page just fine, albeit with an “unsecure” icon indicating that the site had not yet been secured with an SSL certificate. Likewise, it appears Certbot itself can’t find the newly registered domain either, just like Google Chrome. If you happen to have multiple browsers, try visiting your domain from different browsers to see if you can duplicate what I’ve described above. If you find that your website isn’t showing up yet, give your registrar and the World Wide Web a little time to process things and try again.

Run into the following bug trying to get TypeScript up and running in VSCode on your Windows machine?

The file tsc.ps1 is not digitally signed. You cannot run this script on the
current system. For more information about running scripts and setting execution policy, see
about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170.

Okay so here’s the deal. You probably installed the TypeScript compiler using the Windows Command Prompt or possibly the built-in PowerShell terminal from within VSCode. Installing TypeScript using the Command Prompt or the built-in terminal in VSCode will both cause your system to throw the nasty error above when you actually attempt to start using the TypeScript compiler.

Okay so… then what do we need to do? Well here’s your answer:

First, uninstall TypeScript.

$ npm uninstall -g typescript

Next, open up the Windows PowerShell (not the built-in PowerShell in VSCode) making sure to run the program as an administrator. If you don’t know how to do this, search for “PowerShell” in the search bar next to the Windows Start Button in the lower left and corner of your screen. Then right-click on “Windows PowerShell” and select “Run as administrator”. From the Windows PowerShell, you can now re-install TypeScript with administrator privileges which will fix the permissions related bug mentioned above.

$ npm install -g typescript

Now go ahead and re-open your TypeScript project in VSCode and compile it like normal, and everything should work A-okay 👌.

Getting to hello, world in Django is kind of a pain. If you find yourself having some trouble getting up and running on your Windows machine and want to get to “hello, world” as quickly as possible, I hope you find my cheat sheet below helpful. This isn’t really tutorial. For that, I suggest going through the official Django Polls App Tutorial. However, if you just want a quick reference for the future, this is the guide for you!

Having trouble figuring out how to contribute code to someone else’s GitHub repo? Git can be quite complicated, so there’s no wonder why you might be having trouble with this. In fact, I found myself today struggling with this same issue attempting to contribute to an open source project for the first time. Thus, here I am writing this post, more or less for my own personal reference. So without further ado… How to Contribute Code to Someone Else’s GitHub Repo

First, you are going to want to fork the other user’s project. This is not intuitive at all. One would think that simply cloning the users project to your local machine and submitting changes from your local project would make the most sense, but this simply isn’t how it’s done. You are going to want to press the “fork” button on the other user’s GitHub.com page to get started. This is your first step.

Next, when you are ready to start working on your new feature or contribution, it’s time to create a “feature branch” which you will be using to develop your new feature or contribution. We’ll start by cloning your recently created fork to your local machine:

$ git clone https://github.com/YourAccount/SuperSweetProject.git

Now let’s create the new branch:

$ git checkout -b my-feature-branch

After creating your new branch, make some changes to the code on your local machine remembering to hit the “save” button in your text editor or IDE. After saving your changes, let’s stage, commit, and push your changes to your forked GitHub repository:

$ git stage .

$ git commit -m "my first open source commit"

$ git push origin my-feature-branch

Now that we’ve pushed our work to the feature branch of our forked GitHub repository, we can push the “submit pull request” button on GitHub.com to contribute our code to the other user’s GitHub repository. Note, we will be contributing the code from my-feature-branch on our forked repository over to the master branch of the other user’s repository. This is the default setting whenever you push the “submit pull request” button from a forked repository on GitHub.com. GitHub assumes you are wishing to submit the pull request to the original repository which you forked.

Assuming that the other user accepts our pull request, now we will need to sync our forked repo once again with the other user’s repo. This is another one of those not-obvious quirks that I found hard to grasp at first. Once we submit a pull request from a feature branch to the other user’s master branch, our master branch on our fork will actually be out of sync with the other users master branch. So this last little gem here will let us get everything back in sync:

(Configure a remote for fork)

$ git remote add upstream https://github.com/OtherUsersAccount/SuperSweetProject.git

(Sync Forked Master Branch with Other User’s Master Branch)

$ git checkout master

$ git merge upstream/master

Now everything should all be in-sync. To contribute more code simply go back to step one, create a new feature branch (with a different name) and repeat the steps above.