1. Top 10 Eclipse Juno Features

Eclipse Juno has been released this year and it was the first simultaneous release built on Eclipse 4. In preparation of the release, Ian has been counting down the Top 10 Eclipse Juno Features.

2. Eclipse 4 (e4) Tutorial

Jonas Helming wrote a tutorial series for the new core platform of the Juno release. It introduces the new concepts in the Eclipse 4 Application Platform, aka RCP 2.0. The Eclipse 4 (e4) Tutorial has 4 parts: Part 1, Part 2, Part 3 and Part 4.

3. Ups and Downs with Continuous Integration for iOS Apps (Jenkins, Xcode, Cobertura and Testflight)

Holger Staudacher blogged about the Ups and Downs with Continuous Integration for iOS Apps. He built a full CI system for Tabris including automated test execution, code coverage and publishing to Testflight. In his post he detailed the steps to create the system. This can be quite helpful for you when you plan to build your own iOS app.

4. Must-reads for Java Developers: From Beginner to Professional

Holger has been recommending the same books again and again to fellow developers – for different experience levels. Finally he has put together a list of must-reads for Java Developers.

5. My Top 10 Tips on how to be more productive with the Eclipse IDE

I wrote about my top 10 recommendations that will make your programming life easier and make you more productive with Eclipse in “my top 10 tips on how to be more productive with Eclipse“

6. Tabris – iOS and Android apps written in Java

Jochen announced Tabris (called RAP mobile at the time), an interesting approach for writing multi-platform mobile apps: Tabris – iOS and Android apps written in Java

7. Serial Communication in Java with Raspberry Pi and RXTX

Raspberry Pi is the darling of many developers. Johannes Eickhold wrote an introduction on dealing with serial communication in Java with Raspberry Pi.

8. An OSGi JAX-RS connector Part 1: Publishing REST services

Interested in publishing OSGi services as REST services? Then Holgers blog on the OSGi JAX-RS connector is a must read for you. More interesting reads and updates are available using the REST tag.

9. Loading, caching and displaying images in Android

Efficiently displaying an image from a remote server in a mobile application can be quite challenging on Android. Moritz provides a conceptual walk through of several established patterns to load, cache and display images.

10. Mobile Select-O-Matic

Jochen blogged about finding the right mobile development technology for businesses with the Mobile Select-O-Matic.

If you have feedback or a favorite post you would like to have mentioned, feel free to leave a comment below.

I recently developed a small mobile app for iOS and Android with Tabris and RAP and want to share my way of creating a minimal launch config with you.

There are basically 3 categories of bundles in the launch configuration that my app relies on which I use as a “mind hook”:

1. OSGi and Eclipse Code Bundles
2. Bundles for the embedded Jetty server
3. Bundles for the Remote Application Platform (RAP)

So this is how my launch configuration looks like:

1. OSGi and Eclipse Core

org.eclipse.osgi (Level:-1, Auto:true)
org.eclipse.equinox.ds (Level:1, Auto:true)
org.eclipse.osgi.services
org.eclipse.equinox.console
org.apache.felix.gogo.command
org.apache.felix.gogo.runtime
org.apache.felix.gogo.shell
org.eclipse.equinox.util
org.eclipse.equinox.http.servlet

org.eclipse.equinox.common (Level:2, Auto:true)
org.eclipse.core.commands

2. Jetty Webserver

javax.servlet
org.eclipse.equinox.http.jetty
org.eclipse.jetty.continuation
org.eclipse.jetty.http
org.eclipse.jetty.io
org.eclipse.jetty.security
org.eclipse.jetty.server
org.eclipse.jetty.servlet
org.eclipse.jetty.util

3. Remote Application Platform (RAP)

org.eclipse.rap.rwt
org.eclipse.rap.rwt.osgi
org.eclipse.rap.jface
com.eclipsesource.tabris (optional bundle to enable native mobile apps)

Configuration Arguments

Program arguments:

-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl en -consoleLog -console -clean

VM arguments:

-Declipse.ignoreApp=true
-Dosgi.noShutdown=true
-Dorg.osgi.service.http.port=9090
-Dorg.eclipse.equinox.http.jetty.context.sessioninactiveinterval=0
-Xmx700m

Semi-automatic Bundle Selection

Select the following bundle and “Add Required Bundles” to obtain a working Jetty:

org.eclipse.equinox.http.jetty

For a minimal RAP you only need:

org.eclipse.rap.rwt.osgi
org.eclipse.equinox.ds

Don’t forget to “Add Required Bundles”

If you would like to use the Felix OSGi Shell you have to add the “-console” Program Argument and select all Bundles starting with:

org.apache.felix.gogo.*

Please note:
1. You should not forget to add your own project(s) to your launch configuration!
2. Setting sessioninactiveinterval to 0 forces sessions to never time out. This can be handy for debugging purposes.
3. At the RAP Developer’s Guide you find a detailed listing of all RAP related bundles.

If you have feedback or something to add, please feel free to leave a comment below.

This is a follow up to My Top 10 Tips on how to be more productive with the Eclipse IDE (which you should read before this one). I’ll assume you already know how to launch a Debug configuration for your project in your Workspace.

Note: Click on the images to reveal a larger screenshot.

1. Breakpoints

Basic Breakpoints

This is essential and you probably already know how to use it – the Breakpoint.

In case you’re not familiar with them, you create a breakpoint by double-clicking on the left side of a line of code. The execution of your application will then halt at that point so you can analyze the state and hopefully find the cause of your misbehaving code.

Exception Breakpoints

Sometimes an exception occurs, but you are not sure where (e.g. no stack trace available) or the exception is not logged and not visible. This is the right time to create a global breakpoint that pulls the hand brake if a certain exception occurs.

You’ll find this in the Breakpoints view of the Debug perspective.

Conditional Breakpoints

To speed up debugging by not stopping at a breakpoint everytime, you can add a condition. The breakpoint will only stop your application if the condition is fulfilled – and will not unnecessarily disturb your hunt for the bug.

You can get there with a right-click on your break point > Breakpoint Properties...

2. Detail Formatter

While debugging and inspecting variables/objects in your debug perspective, you might encounter textual representations of objects that are not really meaningful. Usually the .toString() method on an object is used for the debug UI. It’s not the greatest idea to implement the .toString() method just for debugging purposes. Instead you can set up a detail formatter that takes care of the textual representation of your object.

You can get there by right-clicking on the variable in the Variables view, then selecting New Detail Formatter....

3. Logic Structure

Here you can see what a difference a small click can make. Both Views show the same Map object. By activating Logic Structure in your Variables view, you get the “contents” and structure of objects presented as you would expect it for a human reader.

4. Drop To Frame

In case your application stopped at your break point and the interesting things had already happened, you can “Drop To Frame”. This means you can jump back in your stack and then start debugging from there…

5. Inspect and Watch

Inspect provides you basically with the same functionality as the Variables View – you can unfold and inspect the various values of the object. Watch on the other hand enables you to observe a specific Object and see how it changes over time.

6. Change Variable Values

The Variables View can do more than just display values. You can also edit values. I don’t think there is much more to say about it

7. Step Into, Over and Return – Shortcuts

Try to memorize the following function keys. They will greatly speed up your debugging by avoiding constantly having to use your mouse.

• F5 – Step Into
• F6 – Step Over
• F7 – Step Return
• F8 – Run until next breakpoint is reached

8. Step Filtering

With “Step Filters” you can filter out types that you do not wish to see or step through while debugging. This helps you to stay focused on the actual code and does not expose you to the inner workings where you might not even have the source. Have a look at Holger’s Effective Mockito post about Step Filtering in conjunction with Mockito.

You’ll find this in: Preferences > Java > Debug > Step Filtering

9. Remote Debugging

With Remote Debugging you can debug an application running on a different machine. The debugging itself is like any other app that you usually launch from within Eclipse. This is what you need to do:

1. Make sure the source code on your machine and the application on the other machine are in sync.
2. Start the application on the other machine with the following command line parameters:

   java -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005

   suspend=y/n declares whether the JVM of the application you want to debug will wait for Eclipse to connect or if it will start right away.
   address=5005 configures the TCP port to use for remote debugging.

3. Create a Remote Java Application Debug Launch Configuration.
4. Specify the Host and Port for your remote application.
5. Add all the source projects of the application you want to debug to the Source tab.

10. Heap dump + Memory Analyzer

Sometimes you need a bigger picture of the inner workings of your application than you can get with line-by-line debugging – especially for finding memory leaks. In this case you are better off with the Eclipse Memory Analyzer (MAT). My colleague Ian wrote a blog post about how to create a heap dump and analyze it.
Update 21.01.2013: Ian just published an other more detailed article about the Eclipse Memory Analyzer: "10 Tips for using the Eclipse Memory Analyzer"

These are just a few tips regarding debugging. If you have feedback or something to add, please feel free to leave a comment below.

So, I thought I would write about my top 10 recommendations that will make your programming life easier and make you more productive.

Note: Click on the images to reveal a larger screenshot.

1. Text File Encoding

The default setting for saving files in your Eclipse workspace is to use the file encoding of the underlying operating system. However, you usually want to create a platform independent application. To accomodate this,  set the file encoding to UTF-8. Using UTF-8 will prevent problems with special characters if you deploy to a system that runs a different OS, run your build on a UNIX machine or if somebody else works on the code using a different OS. You’ll find the settings in: Preferences > General > Workspace or in your project specific settings.

2. Save automatically before build

One thing I noticed is that people (including me) are constantly hitting Ctrl+S to save or even worse — grabbing the mouse to hit the Save action in the toolbar. This behavior seems to originate from experiences where an application was started from the workspace without saving and of course, changes were then lost. You can save some keystrokes and mouse clicks by enabling Save automatically before build.  This is in: Preferences > General > Workspace

3. Type Filters (for PDE / RCP developers)

Type Filters remove suggestions for certain types (e.g. classes, interfaces) from the “Open Type” dialog, content assist and quick fix proposals. Especially as an RCP / SWT developer you most likely don’t want suggestions for Swing components like Button, Label, etc.

You’ll find this setting in: Preferences > Java > Appearance > Type Filters

4. Use “Step Filtering” for Debugging

With “Step Filters” you can filter out types that you do not wish to see, or step through while debugging. This helps you to stay focused on the actual code and does not expose you to the inner workings where you might not even have the source. Have a look at Holger’s Effective Mockito post about Step Filtering in conjunction with Mockito.

You’ll find this in: Preferences > Java > Debug > Step Filtering

5. Always launch the previously launched application

This option will ensure your last launched configuration is used. In the default setting, Eclipse tries to determine the most appropriate configuration for the currently selected resource — which can be quite annoying. Set this under: Preferences > Run/Debug > Launching

If you want to automatically stop running instances when you start a new one, have a look at Launch an OSGi app and automatically kill its running instance.

6. Store your Launch Configuration in a Project

You probably spend a good amount of time crafting your launch configuration. You can actually store it as a file in one of your projects so you can check it in. This way you can share it with colleagues and save them from reinventing the wheel.

You’ll find this Preference in: Menu: Run > Run Configurations... > Launch Configuration Tab: Common

Hint: You can access the Launch Configurations dialog by clicking the Launch/Debug action in the Toolbar while holding the ctrl key or cmd on a Mac.

7. Make a Launch Configuration always appear in the Menu

If you have multiple Launch Configurations, you can choose your favorite ones and stick them permanently to your Launch/Debug menu.

Go to: Menu: Run > Run Configurations... > Launch Configuration Tab: Common

8. Organize imports on save

Java developers really don’t need to worry about imports in Eclipse. The imports are automatically added to the class file. But, changing or removing code might make some imports obsolete. To fix that, you can Organize Imports by hitting shift+crtl+o or shift+cmd+o on a Mac and your imports will be cleaned up. Or you can enable Organize imports on save and Eclipse will take care of that automatically.
You’ll find this in: Preferences > Java > Editor > Save Actions or in your project specific settings.

9. Format edited lines on save

The code formatter in Eclipse is a very useful thing. It ensures that the code looks consistent in your projects — no matter who wrote it — and can be easily read and understood by anyone else. But, formatting the whole file can seriously mess up a diff between two versions of the file. So ‘format only edited lines on save’ might be the right choice if you want the have your code formatted and still be able to see what was changed in your code later on.

You’ll find this in: Preferences > Java > Editor > Save Actions or in your project specific settings.

You might also want to take a look at the Eclipse Checkstyle Plug-In. This will help you to enforce your coding guidelines.

10. Let Eclipse do the typing

A good IDE should support the developer in writing his code at nearly the speed of thought. And Eclipse comes quite close to this with Refactorings, Quick Fixes, Code Assist/Code completion and more. So don’t type too much yourself — you will, here and there, type something wrong, overlook something, scroll through code, which costs a lot of time. Force yourself to use shortcuts!

Here is an example. If you want to store a method parameter in a field, just set the cursor on the parameter name, hit the Quick Fix shortcut and select Assign parameter to new field. And poof, you’re done. If you need a getter, type get somewhere in your class (outside of a method declaration) and use Content Assist to let Eclipse create the method for you. The same applies for creating setters, the main method, the constructor and more.

• Quick Fix: ctrl+1 or cmd+1 on a Mac
• Content Assist: ctrl+space (for Mac and PC)
• Quick Access: ctrl+3 or cmd+3 on a Mac

aka ctrl+awesome™

• Open Type: shift+ctrl+T or shift+cmd+T on a Mac

Use the Mousefeed Plug-In, to learn keyboard shortcuts.  It gives you a message showing the keyboard shortcut for the action you just performed with the mouse.

11. (Bonus Tip) Get a Solid-State Drive

Eclipse has to handle many small files: source code, compiled files, metadata, local history, git, etc.  And, the hard drive you use has a massive impact on most of the actions you perform throughout the day. A major performance boost , and therefore a productivity boost, can be achieved by upgrading to an SSD. Here is an article from Dr. Dobb’s on that topic.

If you have feedback or something to add, please feel free to leave a comment below.

One thing we noticed, was that the server responses were not compressed anymore by the server. On company networks this might not really matter, but if you’re using 3G or an unreliable WiFi connection, package drops might cause frustration among users.

To solve this issue you need to reduce the data that is transferred or even better, fit it into one IP package. You can do this by enabling GZip compression on the server.

There are two important things to watch for -

1. Make sure the server compresses the JSON responses. RAP uses the mime type “application/json” for the protocol messages.
2. Depending on your server you need to explicitly turn on compression and/or configure when to compress the content (ie. if the content is bigger then a specified size).

For Tomcat, the configuration looks like this:

<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
compressableMimeType="text/html,text/xml,text/plain,application/json"
compression="1200" />

For Apache, the configuration (/etc/apache2/mods-enabled/deflate.conf) looks like this:

<IfModule mod_deflate.c>
# these are known to be safe with MSIE 6
AddOutputFilterByType DEFLATE text/html text/plain text/xml
# everything else may cause problems with MSIE 6
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/x-javascript application/jav
ascript application/ecmascript
AddOutputFilterByType DEFLATE application/rss+xml
</IfModule>

In our case we added the “application/json” mime type and configured our server to compress responses with 1200 bytes and more. If you’re considering having compression always on, think again. Most data under 1000 bytes will become bigger when it is compressed. And, if the data – compressed or not – is not bigger then 1500 bytes, it will fit in one IP package (see MTU). In fact, this will speed up the client-server communication. Your users will experience less latency and less impact from package drops.

In one test run, we created an initial JSON response with about 20.000 bytes. With compression enabled, we reduced that to only 2.000 bytes that were transferred! The result was 10x less data or a transfer that was roughly 10x faster.

In this post I’d like to show you my Xcode experiences and how they compare to the Eclipse IDE we all know and love.

Installation

First of all you need a Mac. It should be at least a Core 2 Duo machine with OS X Lion (10.7) installed. You can download XCode 4 for free at the Mac App Store. Make sure you have enough spare time and bandwidth. Once Xcode is downloaded, installed and started, it will continue to download and install other components like SDKs, iOS Simulators, Documentation, …

For my source code repository, although Git support is integrated in Xcode, I prefer the more powerful (but commercial) Git client Tower. The free Git client from GitHub is ok, too

Some Stuff to Blow Up

In order to get to know Xcode better, you need a project to mess around with. To find an example project, just have a look at the hundreds Apple Sample Projects. In a later blog post I will show you how to create your own project and write some Objective-C.

A nice, small example to start with is the Reachability sample. You can browse and download the sample code by clicking on the “Download Sample Code” button on the top part of the webpage. The downloaded ZIP will contain an Xcode project (folder with resources and classes and a .xcodeproj file) which you can open by double-clicking the Reachability.xcodeproj. The differences in the source code aside, you can browse and edit the same as in the Eclipse IDE.

There are four key aspects of an Xcode project you should know:

1. Project Info
   
   Here you configure the version of iOS  your App should work on. This will affect the APIs you will have available.
2. Target
   A Target is more or less a collection of resources and code that is built against a set of frameworks (libraries or parts of iOS) and other Targets.
3. Target Summary
   
   This is a bit like a mix of an Eclipse Bundle+Feature+Product configuration. The key aspects of your Target are defined here: A Bundle Identifier, Version and other configurations such as on which device class it should run, the splash screen, App icon and the entry point of the App.
4. Target Build Phases
   
   This is the equivalent of the Eclipse build.properties. This configuration part contains the resources to include, the classes to compile and the dependencies on other Targets or frameworks.

Features

The Xcode IDE contains most of the things you need for iOS development: writing code and unit tests, and analyzing, debugging and deploying your application.

Xcode 4 features a single window layout, called the workspace window, that looks very similar to Eclipse. Besides editing code, there are five actions that you can perform with Xcode:

• Run (To run and debug your App)
• Test (Execute your Unit Tests)
• Profile (Memory Analyzer and other Instruments)
• Analyze (Static Code Analysis)
• Archive (This is the first step to deploying your App to a device or to the App Store)

Run

Like the Run & Debug actions in Eclipse those actions are performed on Launch Configurations – in Xcode they are called “Scheme with Destination”.

You‘ll find Actions and Schemes with Destination on the top left of the IDE.

Usually you select your Scheme (Launch Configuration for your App) and choose your Destination. The Destinations range from iPad / iPhone Simulators in different iOS versions to the devices that are currently connected to your machine.

Executing the “Run” action will run the selected Scheme on the selected Destination.

In Eclipse, Run and Debug are separate actions. In Xcode, on the other hand, you can debug with the Run Action. The default settings will compile and run all the code launched from within Xcode in debug mode. If you don’t want to include debug instructions,  Archiving will compile your App for distribution. It is a good idea to create some test distributions as the debug instructions may be affecting your App’s performance.

To close on the Run&Debug topic, along the way, you may encounter some problems with your code’s memory management. Make sure you always have a breakpoint on objc_exception_throw and enable the options

NSZombieEnabled = YES;
NSDeallocateZombies = NO;

in your Scheme to debug retain and release problems. For more information, see the “Finding Memory Leaks” section in Apple’s Debugging Applications document.

Test

Test driven development in Xcode is quite similar to Eclipse with JUnit. Just import SenTest (included in Xcode 4) in your test classes:
#import <SenTestingKit/SenTestingKit.h>
Then create your setUp and tearDown methods. Test case methods are prefixed with test and if you need a mocking framework, I suggest taking a look at OCMock.

The IDE integration and support of test driven behavior is sort of suboptimal. There are no Quick-Fixes like in Eclipse to create classes, methods and etc. from within your test classes. And the result of your tests are displayed as compile errors in the Xcode UI. There is also no real test reporting UI or a red/green indicator.  When your tests are successful, an overlay will be displayed for a couple of seconds saying “Test Succeeded”.

Profile & Analyze

For more advanced analysis of your code, the Analyze action does a really good job with static code analysis in finding common coding mistakes. The Profile action provides you with a set of tools to find issues in your app – ranging from memory to performance problems.

Archive (aka Deployment)

Archive can be compared the the Eclipse Product Export. To enable the Archive action and export your App, you need to have ‘ iOS Device‘ or a real device selected as Destination. Then you can use the Archive action from the menu: Product -> Archive. Your archived App will now appear in the Organizer. From here you can export the .ipa to install it to a device or send it to the App Store.

Apple provides you with two ways to distribute your Apps. The iOS Developer Program for Individuals and Companies ($99 / Year) is used to distribute your Apps via the App Store and up to 100 test devices. The iOS Developer Enterprise Program allows you to create proprietary in-house Apps for an unlimited number of users within your company (not via the App Store). Of course you can always start coding without subscribing to a Developer Program, but then you will be limited to the Simulator.

To provide the App .ipa to your 100 testers, you can host your own ad-hoc installation website or just use the free TestFlight service.

Refactorings

Check. Well, kind of… Refactorings can be done to a certain extent. You can rename local variables, extract methods, … but it is by far not comparable to what Eclipse JDT offers.

Continuous Integration

Continuous Integration (CI) is also possible with Xcode. Most of Xcode’s functionality is accessible from the command line to automate building, testing, etc. with the common tools like Hudson/Jenkins. Have a look at Holger’s blog entry about Continuous Integration for iOS Apps.

Keyboard Shortcuts

In the Eclipse IDE I use shortcuts all the time. I compiled a list of Xcode Hotkeys for the most common actions I also use in Eclipse:

• Switch between the Header and Source file
  • Control + Command  + Up Arrow
• Display documentation
  • Option + Click
• Jump to definition
  • Command + Click
• Autocomplete
  • Control + Space
• Rename in File
  • Control + Command + E
• Beginning and end of a line
  • Command + Left Arrow
  • Command + Right Arrow
• Jump between words of a line
  • Option + Left Arrow
  • Option + Right Arrow
• Open Type
  • Command + Shift + o
• Outline
  • Control + 6
• Comment Selection
  • Command + /
• Kill line to the end of line
  • Control + K
• Run
  • Command + R
• Test
  • Command + U
• Clean
  • Shift + Command + K
• Switch to the previous opened file
  • Option + Shift + Left Arrow
• Switch to the next opened file
  • Option + Shift + Right Arrow

Interested?

Once you know how things compare to Eclipse it should not be too hard to find your way around Xcode. Especially in the beginning, the Apple Documentation (Objective-C, iOS) helped me a lot. Honestly, it’s the best documentation I’ve ever seen. And on iTunes U, you have free access to iOS development lectures in video podcasts for free from Stanford University.

Of course StackOverflow is also a great community to get answers and hints on problems you may encounter. If you have other tips for Eclipse developers getting started in Xcode, it would be great to see your comments here.

As you may have heard, we launched RAP mobile two days ago. And, we did just that. With RAP mobile you can access exactly the same dataset with exactly the same code as in Ralf’s post. The dataset contains over 500,000 emails totaling over 2GB of space. Check out the screencast below and the source code on github.

What I find intriguing about this framework is that it is fast. There is no data on the phone. The information displayed in the UI is retrieved asynchronously from the server while the user is scrolling through this enormous set of data. The native iOS client takes care of the proper preloading, caching and memory management.

At the same time as doing all that, we worked to get the Yoxos SecureSource validation process certified by TÜV. Turns out that the TÜV certification is perhaps the news of biggest impact to the community. It means that you can now get thousands of OSGi and Eclipse components that have been validated as trustworthy using a process certified by an internationally recognized standards body.

Most Germans will know TÜV from the inspection they have to do for their cars every two years. TÜV engineers certify cars as roadworthy and safe. But TÜV does way more than that. It is a global organization specialized in testing, inspecting and certifying product safety, quality and usability in many areas. We looked around the office and found the all of these everyday TÜV certified things.

In addition to things impacting your physical safety, TÜV certifies all manner of software including virus checkers and now software component validation processes.

Why is this interesting?

Basically there are whole industries out there that cannot use Eclipse and open source because it’s seen as untrusted. This certification of Yoxos SecureSource means that Eclipse and OSGi can be used in security critical applications or mission critical toolchains where trust and validation are key concerns. More users of Eclipse in more domains means a bigger ecosystems and more adoption. Good news for everyone!

For fun, we looked around the office and found the all of these everyday TÜV certified things and thought it would be cool to run a contest. The first person to correctly identify 5 of the pictured TÜV certified products wins a free lifetime subscription to our new super secret Yoxos product coming out by the end of the year.

Submit your entry by commenting on this post.

Here are my talks that were accepted:

1. My workbench on your desktop? The Yoxos OnDemand free download configurator.
2. Down with WAR. Server-side deployment with p2
3. EPP Wizard – The Future for Custom Eclipse Downloads

I’m looking forward to meet you all there at the conference.

Don’t forget to vote for the committer shirt contest, book your Hotel and bring your power outlet adapters…