Spray away from face

Tag: workflow Page 1 of 3

Git Bundles – A Beginner’s Guide

I recently ran into a situation at work where I needed to share a Git repo “across an air gap.” In other words, I needed to be able to read a Git repo without actually having read access to the Git repo. I did some research and found out that this can be done with Git Bundles, but when I tried to look for info on how to actually USE Git Bundles, I mostly found a lot of Stack Overflow and Reddit threads with 23 year old know-it-alls providing helpful tips like “That’s stupid. Why would you ever need to do this?” The answer is that you work for a financial services company and they are paranoid to give developers access to anything that exists on the internet. Anyway, enough ranting. I pieced together a method for using Git Bundles that worked well for me and I thought I’d share it.

So here’s the setup:
A company we’ll call “OutsourcePro” is hired to build an application for your employer, who we will call “FullTimeJob.” OutSourcePro uses private Bitbucket repos for all of their projects and they offer to provide the devs at FullTimeJob access to the repos for purposes of doing regular code reviews. Unfortunately, FullTimeJob is a financial services company and finds the internet to be too scary to allow anything like Git repo access. So, FullTimeJob’s developers are told that they can’t have the access.

OutSourcePro offers to send a giant zip file with the entire project at intervals of their choosing (rarely or never). But, FullTimeJob’s developers find out about Git Bundles. FullTimeJob devs tell OutSourcePro to provide a Git Bundle every Tuesday and Friday. This will allow FullTimeJob devs to review the changes without needing to read every single line of code to figure out what’s different. FullTimeJob’s security experts agree that receiving a giant zip file via email twice a week is more secure than accessing a private Git repo directly (um… okay). Great! But, now what? The interwebs have very little useful info on how Git Bundles actually work. So, a developer at FullTimeJob does some experimenting and comes up with a plan:

Method 1: One-way Traffic
This assumes that all development work is being done by OutSourcePro and that FullTimeJob’s developers only need read-access for code reviews and whatnot. Developers at FullTimeJob will not be committing or pushing any code.

  1. OutSourcePro creates a private Git repo (on Github, Bitbucket, or somewhere else).
  2. FullTimeJob creates a corresponding Gitlab repo on their proprietary, enterprise Git server.
  3. OutSourcePro does daily work and pushes ALL changes to to their private Git repo (including work in progress)
  4. On Tuesdays and Fridays, an OutSourcePro developer pulls ALL commits from ALL branches to their local repository.
  5. The OutSourcePro developer creates a git bundle:
    git bundle create outsourcepro_DDMMYY.bundle –all
  6. The OutSourcePro emails the bundle to FullTimeJob
  7. A FullTimeJob developer copies the bundle to their Desktop and clones it to a new folder:
    git clone /Users/FullTimeJobDev/Desktop/outsourcepro_MMDDYYYY.bundle
  8. This will clone it into a folder named for the bundle: outsourcepro_DDMMYYYY
  9. The FullTimeJob Developer should then point the origin of the new local clone to their private enterprise Git server:
    git remote set-url origin https://ftjgitlab.com/project/repo-name.git
  10. Once the origin has been set, the FullTimeJob developer can push all changes from the local clone to the enterprise remote.
  11. Once all the changes have been pushed, the local clone should be deleted from the FullTimeJob developer’s Desktop.
  12. Now, all FullTimeJob developers can fetch/pull the changes from the enterprise remote to their local repos.

Basically, this process allows you to make a duplicate of the Git repository on your own server and keep up with the changes being made by the OutSourcePro team.

Method 2: Two-way Traffic
What if developers on BOTH teams needed to make changes to the code? This use case is actually very similar, with both teams sending Git bundles to each other and following the process above. But there are a few tips I will suggest to make it easier:

  • Don’t cross the streams! Before starting the project, decide what each team will name the branches on their Git repos, and make sure that the two teams are ALWAYS USING SEPARATE BRANCHES. Same-named branches will cause chaos. In our example:
    • FullTimeJob will eventually own all of this code, so they name their main branches “dev” and “master.” All other branches on their end will be named “ftj-something.”
    • OutSourcePro will eventually hand over all of the code, so they name their main branches “osp-dev” and “osp-master.” All other branches will also be named “osp-something.”
  • Decide who will do the merging into the final repo branches. Again, in our case:
    • FullTimeJob will own the code and the final project will reside in the “dev” and “master” branches create by FullTimeJob. So, only FullTimeJob developers are allowed to merge code into these branches.
    • Similarly, OutSourcePro owns all of the “osp-” branches and only OutSourcePro devs are allowed to merge anything into those branches.
  • Both teams should be merging the other team’s work into their branches regularly and resolving the conflicts.
  • Nail down specific times when new bundles will be delivered to each team so that the syncing and merging can be done at scheduled times.

That’s it! I suggest testing this out internally before you try to do it in a real-life scenario. Have two developers act as members of the two teams. One developer can create a git bundle and send it to the second dev, who will follow the process of trying to duplicate it to a new repository. Then, have the first dev make some commits and send another Git bundle to the second dev who tries to add the changes to their duplicate repo. Good Luck and let me know if I missed any important details!

Running XCode projects on a device without a developer account in XCode 7

One of the announcements at WWDC 2015 was that developers would be able to test apps on devices without a paid Apple developer account in XCode 7. I was just about to drop $99 on a developer account so I could test a personal project on my devices. So, I decided to dig in and figure out how to do this.

IMPORTANT NOTES BEFORE YOU START:

  • You can’t do this if you have any developer accounts in XCode. This makes sense, really. If you have a developer account, then you can already test your projects on a device and you don’t need to do this.
  • If you follow the steps below, your accounts will change across ALL versions of XCode on your Mac. So, if you need to keep your developer accounts in XCode 6, do NOT follow these steps.

Now that you’ve been properly warned about the ramifications, let’s get started…

Step 1: Download XCode 7 beta. Please note that XCode  7 beta is still pretty rough and you may need to go back to XCode 6 for certain things.

Step 2: Remove any developer accounts in Xcode. Open XCode Preferences and go to the accounts tab. You can’t have any accounts in here that are connected to any Apple Developer accounts. This means that you can’t have a paid developer account, but it also means that your Apple ID can’t be part of any free developer accounts (like Safari development). If there are any developer accounts in here, you need to delete them. The easiest thing to do is simply delete ALL of the accounts listed in here, then add them back in later as needed.

Notice how the Apple ID I’m using says “Free” under the iOS and Mac headings:
xcode_acct_prefs

Step 3: Open an Xcode project and connect your device to your Mac.

Step 4: Check your project build settings. Choose your project target in your XCode project settings and go to the Build Settings tab. Make sure that your Code Signing is set to iOS Developer and your Provisioning Profile is set to automatic.
xcode_provisioning

Step 5:  set target device in XCode as shown:
xcode_set_device_target

Step 6: Run the app from Xcode

Step 7: Choose the account you want to use. If you deleted all of your accounts in step 2, you will be prompted to sign in with an Apple ID. Again, you must use an Apple ID that is not tied to a developer account.

Step 8: Apple may prompt you to fix issues with your certificate or provisioning profile. If this happens, click the “fix issue” button and let Xcode handle it for you.

If this process fails for any reason, here are some other things you can do:

  • Open Keychain Access on your Mac and delete any development certificates in here. I had some old, expired certificates in my keychain and deleting them cleared up some problems.
  • Go back to XCode preferences and check that the Apple ID you used is not connected to any developer accounts
  • Worst case scenario: remove all accounts from Xcode preferences and create a brand new Apple ID with a new email address. This should force XCode to use a free account.

Just like any normal Xcode provisioning, it sometimes takes a little fiddling around to get it working. If you find any other tips, leave them in the comments.

Good Luck!

Using Intellij IDEA for Actionscript Development

I’ve been a die-hard Windows guy for a long time, but this year I switched to using a Mac so I could learn some iOS development. Since I made the switch, there are a few PC-only programs I miss. One of them is FlashDevelop – which I use(d) for all of my Flash/Actionscript work.

Flash is dying – that’s a fact. Not many new projects are being built in Actionscript these days, but I still get some Flash work trickling in now and then. I’ll also have a need to maintain or update older Flash projects for a few more years, so I need a good Actionscript IDE on my Mac. I tried running FlashDevelop on Parallels, but there were a few nagging problems with it that made it less than optimal. After doing some research on Actionscript IDEs for the Mac, I settled on Intellij IDEA. I was already using PHPStorm and I liked it a lot, so I thought I would give Intellij a try.

It’s been a great IDE for AS3 work. I like it almost as much as FlashDevelop, but the documentation is lacking a bit. Figuring out how to tweak the project settings was a hassle, so I made a video tutorial showing how to set up an Actionscript project in Intellij IDEA:

BTW, Intellij IDEA is an awesome all-around IDE that is definitely worth the $200 license. I use it for basically everything. Check it out for all of your HTML, CSS, javascript, PHP, Ruby, Rails, and JAVA needs.

How To Use Firebug to Fine-Tune Mobile Website CSS

If you are doing front-end web development, you likely use Firebug. It’s a Firefox browser extension that provides all the basic tools you need to debug a website. Development tools in all of the modern browsers are based on the gold standard set by Firebug.

One of the most common uses of Firebug is to make changes to your CSS in real time. You can experiment with different styles until your layout looks right, then simply cut and paste everything into your stylesheet.

This works great for desktop browsers, but mobile browsers don’t have development tools. If you want to debug your mobile layout, you need another browser extension that allows you to switch the user agent. There are a number of good ones out there. I’m currently using User Agent RG for Firefox. Once this extension is installed, you can change the user agent string by going to the “Tools” menu and choosing “User Agent.” Simply choose a mobile device and you can get an idea of what your site looks like on a mobile device.

It’s important to understand what the user agent switcher does (and doesn’t do). What it does is tell the browser the type of device that you are using to browse the web. The Firefox plugin basically lies and says “I am using an iPhone” (or whatever). If you have a mobile version of the website, that version will be displayed.

What it does NOT do is make Firefox act like Mobile Safari, or any other browser. If there are browser-specific layout issues, you will not be able to see them with the user agent switcher. Luckily, mobile device browsers are fairly standards-compliant, so very few CSS issues are browser-related. Browser-specific issues like HTML5 video issues (*cough* Mobile Safari *cough*) still need to be debugged with that browser.

The other thing that user agent switching doesn’t do is resize your site to mobile browser dimensions. To get an accurate sense of how your site looks on a phone or tablet, you will probably need set a body width in your CSS:

body {
    width: 320px; /*older iphone width*/
}

This way, you can lock it to the dimensions of the device you want to test and tweak the CSS with Firebug to fix any layout problems.

This has been the quickest and easiest way I have found to fix mobile-specific layout issues. Good luck!

Page 1 of 3

Powered by WordPress & Theme by Anders Norén