Was ist der Unterschied zwischen “http” und “https”?

Für nicht Eingeweihte ist der Unterschied von “http” und “https” nur ein Buchstabe. Es erscheint wie ein kleiner Unterschied, sonst nichts. Es steckt aber sehr viel mehr dahinter.

Erklären wir das mal anders: Wird eine Webseite mit “http” aufgerufen, dann wandern die Daten wie auf einer Postkarte durchs Internet. Jeder kann sich die Karte greifen und durchlesen. Password, Private Nachrichten, Absender, alles. Jeder, der die Postkarte in den Händen hält, kann Worte durchstreichen oder ändern. Auf einen Postkarte schreibt man deshalb auch nichts privates, nur Urlaubsgrüsse und so. Postangestellte sind im Grundsatz ehrliche Leute, aber Privates ist halt privat.

“https” (ein Buchstabe mehr) ist wie ein Brief im Umschlag. Nicht jeder kann den Brief lesen, öffnet jemand den Briefumschlag, dann kann der Adressat es erkennen. (Institutionen, die einen Brief öffnen und wieder schliessen können, ohne das der Adressat es merkt, werden das auch weiterhin tun, https hin oder her.)

“https” bietet also etwas mehr Privatssphäre.

User Interface Design Without Programming

A new project is starting. You are in front of a prospective client and are demonstrating the way your solution will solve their problem. You have explained your proposal, you went over how you address customers needs and then the client is asking that dreaded question: “Can you show me something?

How to discuss user interfaces with clients?

Most clients will be nontechnical. Clients are thinking in terms of their own business and usually their business has nothing to do with designing software. They want to have a problem solved and prior to signing the order they want to know how you will go about it.

So they want to see the GUI. But a GUI will require a running logic behind it. You are stuck with a chicken-and-egg problem: write the logic to handle the GUI before knowing what the client is expecting from the GUI. What about usability? It is not yet about styling, just to know which button goes where. This is not a new problem, there are several ways for handling it.

There is paper prototyping. It is seen as a good way to design user interfaces. After all, pencil and paper are a common commodity in an office. There is no ramp-up phase trying to learn a new tool. Freehand drawing might not be nice but everybody can do it. Buttons, lists and other widgets can be designed as needed. Most importantly, the client will understand why after the design and usability session(s) there is still lots of work left in the project. Work as in: writing code, testing for usability, performance verification and so on. All that paper drawings have to be transferred into bits and bytes.

The problem with paper prototyping is that it is a physical activity. As such it does not fit well into our modern style of working remotely and telecommuting. Clients work from their offices not ours. Getting a few minutes of screen-share-time via internet is rather easy. Traveling to the clients offices for a meeting in person will consume a lot of time. Sometimes it is not even feasible due to distance. Most project stakeholders simply will not be in the same office. Discussing and aligning with them can be a challenge unless somebody really enjoys scanning paper into electronic format.

So there are limits to how far a paper prototype can work. However there are many GUI Prototyping Tools. Some are integrated into developer IDEs, some are part of the tools that graphics designer use. One example is StoryBoards in Xcode, others are listed here.

We want a tool that can simulate our GUI, that does not require code or even programming and that is reasonably easy to learn and use. This post is about MockupScreens, kindly provided by the author Igor Ješe.

Getting Started

MockupScreen is available for OSX and Windows. Installation on both platforms is painless. On OSX it is a matter of dragging the app to the Applications folder. On Windows the application installs to a user writable directory, no administrator rights are needed. The app can be tried and tested for 30 day before purchasing, so it is worth taking it for a spin.

The app interface window is divided between the main work area and the helper areas. In the main working area the forms (the screens) are created. Positioned around the work area are: the widgets list on the left, the widget properties and the comment section on the bottom and the navigator area to the right.

Creating a GUI

Setting up a GUI screen and adding widgets is only a matter of dragging and dropping from the list to the form. Each widget has its own properties, plus it can be assigned a comment. Widgets can be aligned and positioned as needed using mouse or keyboard. I am a keyboard person, so I like to tune the position of the widget by typing the coordinates. Alternatively the widget can be dragged into place using the mouse.

The kind of widgets available cover for most needs. There is no direct iPhone support but still it is possible to design an iPhone or iPad UI with the components available. An UILabel is a “Text”, a UITextField is a “Field”. Sliders seem to be difficult to emulate however the other elements are doable out of the box.

Every widget can have a comment. This comments area is one of the things that makes MockupScreen interesting. Think of the review session with client and stakeholders. All those notes and feedback gathered can be inserted right next to the applicable widget. Great! No more post-its stuck to the printouts.

Another interesting feature are the skins. Skins change the look & feel of the forms and the widgets. With a single click of a button the same screen can be made to look like a windows form or like a OSX form. Coming back to the example from the introduction above, where a customer want to see something to get an idea: the Black&White skin will create just that impression that says ‘this will be the behavior of the GUI, it is only a mockup, it is not yet a finished App’.

Share and Collaborate

Most projects will be made up of more than a single screen. To the right of the main working area is the screens panel. It will hold the screens that are part of the project and it is acting as a navigator. Screens that relate can be grouped together. This way maintaining an overview even when the project is becoming larger. For example your input/output screen make up one group, results screen are another group and so on.

Groups (scenarios) can be imported, benefitting from previously created work or by merging in work done by a fellow team member. Mockups can be exported to HTML and PDF for archiving and documentation. The export to PDF or HTML format is static without animation present in the output. 

Exchanging mockups between Mac and Windows is possible without modifications, just moving the mockup file across. A project team with a mixed computing environment is not locked into one platform. There is no linux version.

Animate It

So far we have a static UI, we could have done this in most IDEs. In MockupScreens your UI can become alive. And this is a feature that makes MockupScreen really useful.

Widget can be assigned a link to another screen. Pressing a widget, for example a button, will switch to the linked screen. It is called a slideshow. Think of it as being a presentation of screens (slides) that can animate back and forth emulating the behavior of the UI.

In a paper prototyping session the user would shout out the action and the paperboy will shift the cutouts. With a MockupScreens slideshow the user (the client) can use the new UI directly, while you lean back, monitor, observe and take notes. All this without writing a single line of code. You can put your client and your users right in front of the slideshow and let them have a “play” on their own. You can observe and collect feedback.

Modifying the slideshow is as fast as you can point and click. For example a previously prepared scenario can be loaded in in order to have the user to go through an alternative. Because there is no compile time the interruption to the user is minimal.

Summary

The time to learn MockupScreens is brief. Animated UIs can be created without writing a single line of code so there is no need to be a programmer. Changes to the design can be implemented quickly effectively speeding up the refinement process, allowing for more iterations. The user can be involved right from the beginning using the animated screens. Feedback can be tracked using the comments field, even if is only a reference number to the company’s issue tracking system. Different skin can change the look & feel.

There are a few things that can be improved with MockupScreens: The background color for the OSX skin is hard wired and some of the fonts are small to read. Under OSX tabbing through the properties jumps over the “Change” button, something that works fine under MockupScreens for Windows. Nothing really being a show stopper, just those little things that could be better.

Support for MockupScreens is responsive and more than willing to help. When contacting the support team it was confirmed that above mentioned items are already on their to-do list. 

Overall I consider MockupScreens as a useful addition to my toolset.

The home of MockupScreens is at mockupscreens.com. A single user license is US$99. Multi-seat, corporate licenses and educational discounts are available

Translating your iPhone and iPad Project

NSLocalizedString and genstrings

There are many tutorials on the web explaining how to translate an iPhone or an iPad project. Some tutorials are written for Xcode3, some are for Xcode4. Most tutorials on the web use the macro NSLocalizedString(<#key#>, <#comment#>). While localizing projects some challenges were encountered when using NSLocalizedString. We do the translations for German and Italian in-house, for other language the services of ICanLocalize (affiliate Link) are used. When project grow in size, during updates or in the maintenance phase NSLocalizedString has shown some limitations.

Lets start with an example to get everybody on the same page:

In your code the text of a label is set:

 [self.theLabel setText:(NSLocalizedString(@"theKey", @"Hi"))];

Then genstrings is used to scan the implementations file (*.m) and to write its output to the language project folder (here: en.lproj)

genstrings -o en.lproj/ *.m

In the directory en.lproj/ we then find a file called “Localizable.strings” with the contents similar to :

/* Hi */
"theKey" = "theKey";

The comment /* Hi */ is taken from our source code. “Hi” should be string to display to the (english speaking) user. So we need to edit the string on the right hand side of the equals sign and make it the greeting, = "theKey" has to become = "Hi":

/* Hi */
"theKey" = "Hi!";

So far so good

All this is fine if there are a few strings only or when you intend to never modify the strings. The moment you run gestrings again it will overwrite your modifications and you lose your work. If you write the output of genstrings to a different location you will have to manually merge the changes. Once your Localizable.strings file grows it becomes a nightmare trying to keep source code and Localizable.strings in sync. So we want to avoid that.

For several reasons changes to the NSLocalizedString(<#key#>, <#comment#>) crop up. A typically workflow here is to write the program with the English language in mind, then to do the German and the Italian localization. Despite of repeated proof reading there is always a spelling error left. Other reasons for modifying the strings tends to come up during the review sessions with ICanLocalize (affiliate Link) when the translator has made suggestions that should flow back into the original text.

A big help comes from using NSLocalizedStringWithDefaultValue(<#key#>, <#tbl#>, <#bundle#>, <#val#>, <#comment#>). This macro will let us set a default value in the LocalizedStrings file and will make the need for the initial edit of the value field to go away. Don’t be scared about all the fields, I’ll explain:

NSLocalizedStringWithDefaultValue
the macro

<#key#>
same as in NSLocalizedString. The identifier to tell the App which string goes where

<#tbl#>
the table from where the string is taken. In our case this table will be the file Localizable.strings (without extension). It is possible to have different files, for example one per ViewController, but it is not a requirement.

<#bundle#>
the App bundle that contains the table. Assume we have only one bundle, then it will the main bundle

<#val#>
the string you want to see on the screen, in our example @”Hi”

<#comment#>
a comment to make translation and managing this stuff easier. Can be a simple @”Hi!” or a more explaining @”informal greeting”

Putting all this it together it becomes:

NSLocalizedStringWithDefaultValue(@"theKey2", @"Localizable", [NSBundle mainBundle], @"Hi!", @"informal greeting"))

After running same genstrings command as used above there is now a subtle different in Localizable.strings


/* informal greeting */
"theKey2" = "Hi!";

Apart from the comment now being /* informal greeting */ the “Hi!” is already there. There is no need to go to the Localizable.strings file, search for the correct line, modify the field form “theKey” to “Hi!”. genstrings did that for us based on the default value supplied with NSLocalizedStringWithDefaultValue.

Add to it, change it

Now assume you extend your program with new strings. You add the new strings into your source code and rerun genstrings. genstrings will add the new lines into the same Localizable.strings file while maintaining the existing values. Just ensure the values in the source code are what you need.

Maybe at a later stage the audience of your app has changed and you need to be more formal, i.e the “Hi!” should become “Dear Madam, Dear Sir”. The same mechanism applies: update the source code, run genstrings and the value for the greeting is changed plus the new string are inserted. There is no need to manually modify Localizable.strings. You make all modification in your source.

NSLocalizedStringWithDefaultValue became a great time saver and by using this instead of NSLocalizedString making changes to the translated strings is much easier.

Do you have hints that make localization easier? Let us know in the comments.

Getting started with programming for the iPhone

The previous posts looked at setting up the developing environment. Let’s look at getting familiar with the programming language.

Traditionally iPhone apps are written in Objective-C and Cocoa Touch. Objective-C is a C dialect. It is object orientated as other programming languages but relies heavily on the Cocoa Touch and iPhone OS API’s.  Cocoa Touch is the user interface part. Cocoa (without the Touch) is the desktop Mac equivalent.

These API’s cover a vast scope. Learn them and do not fight them. If you eventually want to get your App into the App Store then stay away from private API’s. Often a public API can be made to do what you want.

How to learn it?

The internet is full with tutorials. Cocoa with love and iCode Blog are good places to start if you have never used Objective-C before. on Mac Research a long list of tutorials by Drew Cormac is available. Drew is writing for both Mac OS and iOS and show good solutions to typical programming problems.

If you are more after a video style presentation look at the courses made available by Stanford University and Apple have. The iPhone programing course CS193P can be found as video podcast in iTunesU under Stanford University course CS193P.

The course is presented by Alan Cannistraro and Josh Shaffer, who are also hosting many quest lectures.

The course is a full university course that will require some investigations and follow ups. On the other hand and most importantly the course will bring a lot of things into perspective.  It is piecing together the puzzle pieces and clarifies the concepts. The course will talk about how to do things, what to avoid, best practices and so on.

Google for it

If you are looking for help on a particular issue you can always use Google with the keywords “Xcode Objective-C tutorial” plus the issue you are looking for.

If you roughly know what you are after but are stuck and need that just that little help to continue then Stackoverflow.com is another great place to go to. Use the keyword like iphone or xcode (put them into square brackets to narrow you search).

iPhone Dev SDK is a community for software developers interested in the iPhone SDK platform. Founded in March 2008, iPhone Dev SDK was one of the first communities and continues to provide a great community exchanging valuable information. The forum is one of the few places that also talks about non-programming topics like legal and marketing.

See the source

At some point you might get stuck with a conceptual problem or need an idea of how to tackle a programming problem. You long to see how other programmer write their code. There are complete iPhone apps with their source available.

Here is a short list without any intention of being complete nor implying any kind of rating:

WordPress

edit a WP blog from your iPhone/iPod touch/iPad

Wolf3d

a first person shooter famous long time ago on PC like hardware (look for the FTP link

App Mobile Sales

track the sales of your App

Fuel Log

Track, Graph, Save Vehicle Fuel Usage and Costs (Disclaimer: maintained by the author)

Summing it up

Working through the Stanford material will consume some time but is a good starting point. The wealth of tutorial on the net will cover nearly every aspect of iPhone programming. Everybody is an amateur in the beginning but with a little time well spend the next great app is possible.

So you have Mac OSX running and now what?

Get Xcode

To simply download Xcode you will have to register for the free developer program membership registration. Register at the http://developer.apple.com/ and then you can download Xcode from there.

The size of Xcode is somewhere between 2 and 3 Gb. The size changes from version to version as some releases do not contain all packages for all iPhone OS releases, sorry that’s iOS now. Later I will tell you about Base and Target OS version inside Xcode. For the moment lets stay with Xcode.

As it is a large download and it might stop for what ever reason try to use Safari.  Safari can retry, Firefox did not always retried ok. For Firefox download some manager exists but I found Safari easier to use when downloading such a large packet like Xcode.

Install Xcode

After the download you are ready to install Xcode. The default directory is /Developer. You can select a different destination, for example when you need a particular version of iOS. And before overwriting a tried and trusted version of Xcode better choose a different name and install it next to your important version of Xcode.

For example not all betas of Xcode for iOS4 came with the old iPhone os 3.x versions, and you might want to keep the previous version of Xcode.
Recently the preview for Xcode 4 became available, I have put it under /Xcode4Preview4.

Space

The installation of Xcode takes some minutes and will consume around 5 Gb on your boot volume. Several of the unix tools cannot be relocated to a different volume, that is why you are best off with keeping it on the boot volume. I always had the space free and never bother to relocate it to a different volume. Different folder yes, different volume no.

Finding the Icon

During installation and also later Xcode never created an icon on my mac.  Initially I was hunting around trying to find the folder from where to start it. It is under /Developer/Applications/Xcode.app. When it is finally running right-click (CTRL-click) on the icon in the Dock, goto Options and select “Keep in Dock”.

Next steps

With Xcode in front of you you are ready to start coding. Before I send you to the next part head over to Stackoverflow and look at these two entries:

What are those little Xcode tips & tricks you wish you knew about 2 years ago?

alternatives to XCode for iPhone development? (OR: how to make XCode suck less?)

Another a pool of wisdom is the Apple library: Search for xcode and introduction


The next part will look at coding itself: Objective-C and stuff.

iPhone Programming: Do I need a Mac?

Wrong question: Eventually, you will want a Mac.

Programming for the iPhone is done with Xcode. Xcode is a development environment that offers much more than just an editor with some code coloring. It is a bit ahead of the simple
print variable
statement that you put into your code to track down that nasty bug your users complain about.

Along with offering a decent build-in debugger Xcode can analyze memory consumption and search for leaks. After all you are programming for an embedded device. A magical device but still it has limited resources. Xcode can also help you to track and to tune the performance of your app.

Eclipse is a strong competitor. Xcode is the “gets the job done in an elegant way” tool from Apple. It is not bug free and from time to time developers swear about it, but usually it works reasonably well and does the job.

Xcode only runs on Mac OS X. So you will need to run the Mac OS X operating system. But if you run Mac OS X on Apple hardware or inside a virtual machine that sits on top of a host PC is a matter of licensing and choice.

If you already have a Mac with Snow Leopard skip to the next post. If you view this on a Windows or Linux PC read on.

Setup a Virtual Machine with Mac OSX

To run Mac OS X in a virtual machine you need:

  • Instruction from for example iHackintosh
  • Around 20 to 30 Gb of hard disk space free
  • An Intel based PC (sorry no AMD yet)
  • Snow Leopard Retail DVD
  • VMware Player for Windows or Linux (depending on the operating system on your PC) from here
  • Patience

To download VMware player you will need to register with them. That seems to be OK, I did not get spam from them. If you have a license for VM Workstation that is fine, too. Player is the free alternative from the same company.

darwin_snow.iso is the pre made Snow Leopard VMDK that will enable VMWare Player to load Mac OSX. For the URL see iHackintosh, size of the iso is about 18 Mb.

The procedure from iHackintosh does work although the process is not as painless as installing Mac OSX on a real Mac. The advantage is that you get a feeling if you like the general setup (Mac OSX, XCode, Objective-C) without investing all that money that purchasing the Apple hardware will cost you.

Licensing

VMware player and the Darwin_Snow.iso come free of charge. The Snow Leopard Retail DVD will set you back 29€ and gives you the official software plus the license to use it on Apple Hardware. That amount on money is not worth the hassle of getting an obscure version from some dubious source.

The virtual machine on top of a windows host is OK for a test drive but in the long run you will want a Mac, trust me 😉

The licensing will also limit you from installing the vmware-tools into your virtual machine. The vmware-tools allow for things like copy&paste between host and VM, and seamless screen resizing. Running the desktop version of OSX inside a Virtual Machine is not supported by Apple for and there are no suitable versions of the vmware-tools for Mac OSX desktop. If you consider doing development for a professional purpose get Mac OSX Server or get a Mac. Remember the bit earlier about “for Apple hardware only“?

For private use you probably get away with it but check the legal requirements yourself.

Save early, save often

So now you have Mac OSX running and are ready to install Xcode. Before you do any major changes like installing updates or add Xcode into the virtual machine do a backup. VMWare player being the free version does not include the snapshot feature of the VMware Workstation editions.

You can do your own snapshot by exiting from the virtual machine and shutting it down completely. Then on your host computer copy the directory and the files that contain your virtual machine to a secure location. That is the snapshot done.

Next

The next post will cover obtaining Xcode and will talk about some of the options you have with the developer program.

Getting started with iPhone development

How do I get my program on to the iPhone and the iPod touch? I have an idea and want to make it into a program. Where do I start?
You can start with the theory and search the Internet for tutorials and courses. Or you start right away with the practical side and hack code into your computer. This series of posts will take you through the first steps to get started and will point out some resources on the net where you will get more information.

Let’s start by setting up the computer on which you want to do the programming. If you intent to publish your app in the App Store you will have little choice but to learn Objective-C and to use Xcode. If you aim for the Jailbreak world and want to distribute via Cydia you have the choice of several tool chains and several programming languages. The developer exchange section at http://www.hackint0sh.org/ forums will be a good place to start looking.

In this series of posts I will look at Objective-C and Xcode as that is what I am familiar with. I did not look to deeply at the other tool chains that are available. I do use other programming languages for development as part of my day time job but I on the iPhone I use Objective-C.

Read on in the next part.

Liter auf Hundert in anderen Sprachen

Das Internet enthält viele Informationen zum Prius. Es gibt den englisch sprachigen Priuscast vom Allen Huffman. Da sind Foren wie die Priusfreunde.de. Das US Gegenstück ist der Priuschat.com und hier in Italien schaut man ins Hybrid Synergy Forum.

Eine Sprache zu verstehen ist eine Sache, die Masseinheiten umrechnen ist eine Andere. Der Verbrauch in Litern auf hundert Kilometern wird in Italien als Kilometer pro Liter und im englischsprachigen Raum als Miles pro Gallone ausgedrückt. Diesel heißt auf Italienisch Gasolio, Benzin ist “Petrol” in Großbritannien und “Gas” in den USA.

Wie viel sind nun 42 Miles pro Gallone? Ist 68 ° Fahrenheit warm oder kalt? Und wie viel Reifendruck fahren die Leute mit ihren PSIs ?

Temperatur

Wasser gefriert bei 32° Fahrenheit und Kocht bei 212° Fahrenheit. Die Wikipedia hat eine Formel mit der man Fahrenheit und Celsius umrechnen kann. Der Einfachheit halber hier eine Tabelle:




































Celsius -40 -30 -20 -15 -10 -5 0 5 10 15 20 25 30 35 40 45
Fahrenheit -40 -22 -4 5 14 23 32 41 50 59 68 77 86 95 104 113

 

Entfernung

Die europäischen Kilometer sind die Miles im Englischen. Meistens. Canada und Irland zum Beispiel benutzen auch Kilometer. Eine Meile hat 1609 Meter oder 1,609 Km. Annäherungsweise kann man Meilen durch 8 teilen und das Ergebnis dann mit 5 malnehmen und man bekommt Kilometer. Oder man benutzt die Tabelle hier:

Meilen pro Stunde 10 20 30 40 50 60 70 80 90 100 110
Kilometer pro Stunde 16 32 48 64 80 97 113 129 145 161 177

 

Gallonen and Liter:

Die amerikanische Gallone ist etwas kleiner als die Britische (Imperial genannt). Die Amerikanische hat 3.785 Liter, die Imperial Gallon hat 4.546 Liter.

Der Tank des Prius fast ca. 45 Liter, das sind ungefähr 12 US Gallonen or 10 Imperial Gallons:

Gallon (US) 1 2 3 4 5 6 7 8 9 10 11 12
Liter 3,8 7,6 11,4 15,1 18,9 22,7 26,5 30,3 34,1 37,9 41,6 45,4

 

Imperial Gallonen

Gallon (Imperial) 1 2 3 4 5 6 7 8 9 10 11
Liter 4,5 9,1 13,6 18,2 22,7 27,3 31,8 36,4 40,9 45,5 50,0

 

Verbrauch und Miles pro Gallon

Die nächste Tabelle vergleicht die Verbräuche. In der linken Spalte steht die Einheit, die Zahlen innerhalb einer Spalte entsprechen dem gleichen Verbrauch in den jeweils anderen Einheiten.

Zum Beispiel: 5 Liter/100km entspricht 20 km/Liter oder 47 mpg(us) oder 56,5 mpg(imperial)

Liter pro 100 km 3,0 3,5 4,0 4,5 5,0 5,5 6,0 6,5 7,0 7,5 8,0
Km pro liter 33,3 28,6 25,0 22,2 20,0 18,2 16,7 15,4 14,3 13,3 12,5
Meilen pro Gallone (US) 78,4 67,2 58,8 52,3 47,0 42,8 39,2 36,2 33,6 31,4 29,4
Meilen pro Gallone (Imperial) 94,2 80,7 70,6 62,8 56,5 51,4 47,1 43,5 40,4 37,7 35,3

 

 

Reifendruck

Reifendruck kennt man in Bar. Die Luftdruckprüfer haben oft schon PSI aufgedruckt. PSI sind Pound pro Square Inch oder Pfund pro Quadratzoll.

bar 1,8 1,9 2 2,1 2,2 2,3 2,4 2,5 2,6 2,7 2,8 2,9 3 3,2 3,5 4
kPa 180 190 200 210 220 230 240 250 260 270 280 290 300 320 350 400
psi 26 28 29 31 32 33 35 36 38 39 41 42 44 47 51 58

 

Andere Einheiten die ihr umwandeln möchtet? Bitte hinterlast eine Nachricht im Kommentarfeld

MPGs in three languages


A lot of information can be found on the internet about the Prius. There is Allen Huffman with his Priuscast. There are forums like the English speaking Priuschat.com, the German Priusfreunde.de, and the Italian hybrid-synergy-forum.eu.

Hearing or reading a languages is one thing, understanding the measurement is another. Consumption for example is expressed in Miles per Gallon in parts of the english speaking world. Germans use liters per hundred kilometer and the Italians use kilometer per liter. Gas is called Petrol, Diesel tends to be called Diesel but it is Gasolio in Italian.

So how can we understand if 42 Miles per Gallon is a lot? Is 32 degrees Celsius warm, and how much PSI do the others put into their tires?


Temperature

Lets start with temperature. Water freezes at 0 degree Celsius and at 32 degree Fahrenheit. Water boils at 100 Celsius and at 212 Fahrenheit. The Wikipedia has a nice formula for converting
Fahrenheit to Celsius.





Celsius -40 -30 -20 -15 -10 -5 0 5 10 15 20 25 30 35 40 45
Fahrenheit -40 -22 -4 5 14 23 32 41 50 59 68 77 86 95 104 113



Distance

Now look at miles and kilometers. One mile has 1609 meters or 1.609 Km. To convert from miles to kilometer one can multiply by 8 then divide by 5. Or use the table as a rough guide to get an impression:

Miles per Hour 10 20 30 40 50 60 70 80 90 100 110
Kilometer per Hour 16 32 48 64 80 97 113 129 145 161 177


Gallons and Liters:

There are two types of Gallons typically used: the American gallon and the imperial gallon. The American (liquid) gallon has 3.785 liter, the Imperial gallon has 4.546 liters.

The tank of a Prius 3 can hold up to approximately 45 liter or 12 US gallons or 10 Imperial Gallons:

US Gallons

Gallon (US) 1 2 3 4 5 6 7 8 9 10 11 12
Liter 3,8 7,6 11,4 15,1 18,9 22,7 26,5 30,3 34,1 37,9 41,6 45,4


Imperial Gallons

Gallon (Imperial) 1 2 3 4 5 6 7 8 9 10 11
Liter 4,5 9,1 13,6 18,2 22,7 27,3 31,8 36,4 40,9 45,5 50,0



Consumption, MPG’s

In this table below the left most row shows the unit of consumption. The numbers in a single row will be the equivalent in the other Units. Example: 5 liter/100km is equivalent to 20 km/liter or 47 mpg(us) or 56,5 mpg(imperial)

Liter per 100 km 3,0 3,5 4,0 4,5 5,0 5,5 6,0 6,5 7,0 7,5 8,0
Km per liter 33,3 28,6 25,0 22,2 20,0 18,2 16,7 15,4 14,3 13,3 12,5
miles per gallon (US) 78,4 67,2 58,8 52,3 47,0 42,8 39,2 36,2 33,6 31,4 29,4
miles per gallon (Imperial) 94,2 80,7 70,6 62,8 56,5 51,4 47,1 43,5 40,4 37,7 35,3



Pressure

Most people will be concerned about distance, speed and consumption. Some will check the tire pressure form time to time, too. Some will pump the tires harder to save petrol while accepting a harder ride. The unit for pressure is the PSI, the bar and the kilopascal.


I grew up with Bar now the pressure gauges show in PSI, too. Without having it printed on the gauge I could never do a match without calculating.

bar 1,8 1,9 2 2,1 2,2 2,3 2,4 2,5 2,6 2,7 2,8 2,9 3 3,2 3,5 4
kPa 180 190 200 210 220 230 240 250 260 270 280 290 300 320 350 400
psi 26 28 29 31 32 33 35 36 38 39 41 42 44 47 51 58


Any other units you like to convert? Please leave a comment.