<![CDATA[Philip Lawrence]]>https://misterphilip.com/https://misterphilip.com/favicon.pngPhilip Lawrencehttps://misterphilip.com/Ghost 2.19Sun, 14 Apr 2019 19:28:05 GMT60<![CDATA[Lessons From Building an Adobe Launch Extension]]>https://misterphilip.com/lessons-from-building-an-adobe-launch-extension/5cb258ecc307e123f87ab652Sat, 13 Apr 2019 22:04:46 GMT

Late last year, Adobe announced the Adobe Launch Extension Idol, a contest between developers to see who could create amazing extensions. That piqued my interest for sure, as most of the contests Adobe had before were on the analysis, rarely were they on the tech/development side. We had already been planning on building several different Launch extensions, but this contest had pushed me forward to create the Gtag extension. I learned a lot along the way, and I wanted to cover a few key points that you should consider if you're thinking about (or already are!) creating  an extension.

Building a UI is hard

OK, so building a UI isn't that hard, but building a great one is. A clear majority of my time was spent developing the UI piece of the Gtag extension. Adobe is largely hands off with their guidelines around the UI, which can be argued that it's both a good and bad stance to take. They do provide some recommendations, but in the end it is up to you to decide how your extension will look.

Adobe's Spectrum CSS framework is available for you to use, and I suggest at least looking into using it so your extension has the same look & feel as the Launch UI. At the time of the initial Gtag development, I was not aware of Spectrum and only knew about Coral - which I honestly was not a fan of. I opted to stay with the tried-and-true Spectre CSS framework, since that was what I was familiar with and I've had great results working with it.

Before you begin any development though, build out a your wireframes. Design everything before you start development. Like many developers, I have a bad habit of just building a vision instead of taking the time to properly wireframe things, and it always bites me in the butt. I went through several variations of the interface before settling on what I have now.

Lesson: Save yourself the trouble by planning and designing everything first.

The upload process can be a pain

The prerequisites for setting up an extension can make you want to rip your hair out. The current Adobe.io process to create and upload an extension is time consuming with many steps to just get a basic extension uploaded into a development property in Launch.

A few weeks ago, I had the chance to speak with the Adobe Launch product team, and happily they were aware that this was a pain point. Recently, the product team updated the documentation to help clarify the process, but it's still simply a long process. Shout-out to the team for building the npx @adobe/reactor-uploader tool which helps with uploading the extension to the Launch environment.

Lesson: Set aside extra time to learn Adobe.io and Postman if you're not already familiar with both.

Be ready to support your extension

This isn't totally relevant if you're privately releasing, but if you're doing a public release be sure to allocate resources to supporting your extension. This means setting aside time to fixing bugs, adding new features, and of course, answering support requests. Let's be real, the last thing the community wants to see in the extension catalog is a bunch of unmaintained extensions that are buggy or severely outdated. Don't forget that your name is on the extension! Ignoring it will ultimately reflect poorly on you or your brand.

Additionally, I highly recommend creating tutorials and lots of documentation. I personally love GitBook for documentation, but you can use whatever system you're familiar with. The more self-serve documentation and tutorials you create, the fewer support requests will come in.

Lesson: Be a fan of the self-support model as much as possible but remember that supporting your extension should have a long-term plan.

Don't let this article scare you away from building an Adobe Launch extension! Getting your toes wet with extension development is surprisingly easy and rewarding. You're no longer locked into the tags or functions that Adobe thinks is right for you; now you can customize it the way you want to match your business needs. Just keep these learnings in mind and set aside extra time to learn new workflows and tools.

Want more info? Check out Adobe's official documentation on getting started with extension development.

<![CDATA[Adding Code Completion for Adobe Launch Extension Developers]]>https://misterphilip.com/adobe-launch-extension-code-completion/5cb10cf1c307e123f87ab4c8Fri, 12 Apr 2019 20:57:00 GMT

If you've done any extension development for Adobe Launch, you've likely used the turbine and extensionBridge objects in some way. If you haven't dabbled in building an extension and you use Launch, I highly recommend trying it out.  For a quick reference, the turbine object is a "free variable" that provides a handful of properties about the extension and Launch property, as well as a few helper methods. The extensionBridge object is used to communicate settings and validation between the extension's UI and Launch's UI, as well as adding a few additional UI helpers. You can learn more about these objects over on the Adobe Launch Developer Docs.

When I was developing the Gtag extension, I was constantly referring back to the documentation to see the exact name of a property I wanted to grab, the order of arguments to pass into the turbine methods, and the names of the methods on the extensionBridge object. I primarily use JetBrain's WebStorm IDE when developing front end work, and like most modern IDEs, WebStorm has fantastic type hinting and code completion features that I constantly use. In order to make use of this, the original objects need to exist in the project. In the case of building a Launch extension, we don't pull in the full Launch engine or any of the free variables injected into our extension. However, you can add code libraries to fill in the gap, thus, the turbine dummy was born!

You can see below that the various methods and properties are now hinted and can make development a lot easier within WebStorm:

Who are you calling a "dummy"?!

If you've done any type of automated testing before, you've probably heard of the terms "stubs", "mocks", "fakes", and "dummies". They all do similar things, but they each have their own use case. A "dummy" is simply a placeholder. It doesn't add any functionality, it cannot be called by called, but it can be referenced. There isn't an exact term for what we're doing, so a dummy is close enough.

If you're interested in learning more about the other terms, I recommend checking out the documentation over at xUnit Patterns. It might be an older site, but it still has great info on the various terms.

OK, so how do I add it?

You can grab the latest version and instructions over on my GitHub: https://github.com/MisterPhilip/webstorm-turbine-dummy

Additionally, you can learn more about how to install the dummy file in WebStorm by watching the tutorial below:

Other IDEs that have code completion should have similar ways to install a third party library. Worst case, you can always add the file to your project in the root or source directory, and then exclude it via a .gitignore rule.

Hopefully this makes it slightly easier for other developers to build their Adobe Launch extensions. Have feedback or want to contribute? I'd love to hear it! Tweet me at @_MisterPhilip, or submit an issue/pull request in the GitHub repository.