Armagan Amcalar

Armagan Amcalar

Software architect, JS enthusiast, electronics engineer,
Apple fan, guitar geek and stuff.

Chris Leon demonstrates a very nice video where he plays his own implementation of a delay pedal with pedalboard.js, the first and best open source library for developing guitar pedals with HTML5 Web Audio.

Thanks to Chris for his great work!


If Flipboard is Edison, Zite is Tesla.

Today I read that Zite is being acquired by Flipboard.

For the past two years, Zite has been an integral part of my life as I use it at least for half an hour every single day. It’s been a great resource of, well, resources for development. I’ve even been featured once with pedalboard.js.

But all good things must come to an end, I guess. I am a big Zite fan, I even built a web-based interface for Zite to read while I’m not on mobile.

I can’t believe how people think Zite is like Flipboard; it’s far more superior in every aspect. If Flipboard is Edison, Zite is Tesla. Yeah, I liked that analogy.

I’m really worried for the acquisition, as I know nothing good ever comes out of one. I’m glad that, apparently, Mike Klaas is joining Flipboard, but hey; I really dislike Flipboard. It’s a piece of crap compared to Zite, and I find it shameful for such a great product (Zite) being acquired by a such a pompous product (Flipboard). But that’s how marketing goes, I guess.

I will use Zite for the rest of its lifetime, and hope to find all its greatest features in Flipboard. Maybe then I can like it.


Acik kaynak

Anonim turkuler acik kaynak dunyasinin en guzel ornekleridir. Bilginin, kulturun, kalitenin paylastikca arttiginin gostergesi; sahipligin, tekelin, mulkun temelsiz ve basarisiz oldugunun kanitidir.

Acik kaynakli seyler yuzlerce yil yasar, el degistirir, buyur ve herkes kendinden bir seyler katarak yogurur. Basarisinin ve kaliciliginin sebebi budur.

Ticari kaygilarla; ustunluk kurmak, guc elde etmek icin yapilan girisimler eninde sonunda batmaya, unutulmaya mahkumdur.

Tagged: #TR #Thoughts

Epic CG and script writing.


Introducing the baking soda paste technique for fixing rubber-band scrolling on iOS

Baking soda paste is one of the best practices when it comes to dealing with rubber stains or, well, rubber-band scrolling on iOS. This is an in-depth guide to defeat the bad habits of iOS and let your web app vibe more like a native app.

Before we begin, you might want to check out a simple example with the baking soda paste technique in the works, or a more complex example with an app-like layout. Make sure you open the examples in your iOS device.


This little technique lets you deal with the disgusting rubber-band scrolling on iOS devices. With Baking Soda Paste technique, web applications look more like applications than web sites. As an added bonus, the technique hides the address bar in iOS 6, leaving the precious space for the app. A third fix is for web apps in iPhone 5. Due to unknown reasons, by default they appear with black bars on top and bottom.

So, baking soda paste solves 3 problems;

  1. Rubber-band scrolling in iOS Safari.
  2. Hiding address bar.
  3. Black bars in full screen web apps.

Another nifty bonus is inertial scroll everywhere. You know, Safari’s scrolling is not like its counterpart in native apps. It’s made for improving reading experience, some claim. But I find it restrictive. With baking soda paste technique, you get inertial scroll in your web apps for free, without going on a limb and type-webkit-overflow-scrolling: touch on everything.


Check out the repo on GitHub and;

Explore simple.html for fixing rubber-band scrolling in basic terms. This is as simple as it gets. With a few CSS rules, you can prevent rubber-band scrolling on overflowing elements. It doesn’t apply to non-overflowing elements, though.

Explore complex.html for the full technique, including all three fixes. You can mix and match any as you like. It includes a header and a footer along with a content area, as seen in many applications.

Explore complex-annotated.html for detailed inline explanation for the full solution. It helps with understanding quirks.

How to apply

Everybody has a different style when it comes to constructing a web app. Therefore, this technique is as sparse as possible and can be applied in parts to your solution. Just take the simple solution to rubber-banding, or mix and match parts from the annotated source.


The beginnings of a web app

The default browser width is 980px in Safari in iPhone. This is to show whole desktop pages in a very tiny fashion, albeit complete, in that screen. It’s also zoomable by pinching.

A native app uses the actual device pixels, so should we. And there’s no zoom so we should fix that too. In order to achieve this, use the following meta tag.

Now actually, initial-scale=1 makes sure there’s no initial zoom, user-scalable=no makes sure a user cannot zoom in or out, and width=device-width makes sure we use the actual device pixels.

Well, almost. The retina iPhone has 640 pixels in horizontal but this meta tag makes the browser think it has 320 pixels. So you just can’t use 1-pixel-wide design elements. The 1px in your CSS will amount to 2 pixels on screen.

If this is a problem for you (it mostly will be), you can just use a scale value of 0.5 as in:

This makes sure that we really use the whole device pixels, and you can make your designers happy once again by letting them use 1-px-wide elements.


It all began with the disgusting rubber-banding effect. Well the effect is not so disgusting, it’s rather cool in fact (with things like pull-to-refresh, etc.), but you just don’t want it in your web app.

We’ll begin with the rubber-banding effect that are triggered by scrolling past limits in scrolling elements. You know, the ones that have a lot of contents inside. You scroll to the top, and want to scroll further (like when you want to see a pull-to-refresh icon). And when you expect a native app to just scroll the contents, you’re pulling the whole viewport! Now that’s very bad, but it’s actually very easy to prevent rubber-banding in scrolling overflowing elements. An overflowing element is one whose height is smaller than its contents’. It may or may not be scrolling; and although an element doesn’t have any scrollbars, it can be an overflowing element.

For example, inline elements take the dimensions of their surroundings. But a block element in an inline element may be bigger than its container. By default, browsers will display the content fully, but the outer inline element is already overflowing, like with the overflow: visible CSS rule. The same idea may be found in hieararchical block elements; when the inner element goes out of its container, it means the container is overflowing. You can scroll it if you apply overflow: scroll.

So, putting the non-scrolling overflowing elements aside for now, the scrolling elements are easily fixed.

You just apply the following rules to html and body tags:

html, body {
    height: 100%;
    overflow-y: scroll;
    -webkit-overflow-scrolling: touch;

And these to your scrolling element as in:

#content {
    height: 100%;
    overflow: scroll;

Really simple, right? You must have seen other nasty solutions that even try to scroll the element 1px off when you reach an end.

So open up simple.html in your iOS Safari while you enjoy a goodbye toast to rubber-banding. Now let’s step back for a moment and try to understand what’s going on here.

First, you set the height property to 100% for the body and the html. These assure that the body will fill the screen and will not scroll past beyond it. And any overflowing content will be scrolling inside the body.-webkit-overflow-scrolling is another key factor and serves a double purpose. One, it enables inertial scroll on every element and two, it just provides the rubber-banding fix.

Make sure to have a finite height on the content container as in the example, and just applyoverflow-y: scroll. Magic.

Now don’t get me wrong, I have definitely no idea why this works. But it really does.

And how about non-scrolling, non-overflowing elements? Well they are a bit more tricky and cannot be dealth with CSS only, therefore they require JavaScript. But more on that later.

Complex example application layout

The other fixes are demonstrated in the complex example. The example features a header, a content area and a footer as found in many applications, and are fit for such layouts. You can work the fixes out for other layouts as well.

This app layout features a 60px header, a flexible-height content area and a 60px footer.

Hiding the address bar in iOS 6

The address bar in iOS 6 is actually more friendly to developers than its cousin in iOS 7. Although iOS 6 is waning in market share, it’s still out there along with 3:2 iPhone screens. So that leaves a really small canvas for our apps and that’s irritating. So let’s get rid of it!

Now the first thing is, we have to make sure that we’re in iOS 6 and actually in a browser (and not in standalone mode where the user added the application to home screen via the Add to Home Screen button), since iOS 7 doesn’t let you hide the address bar and in standalone mode there’s no browser chrome.

Here’s a very crude and simple OS version sniffer;

if (navigator.userAgent.indexOf('iPhone OS 6') > -1) {

If the user is using a version of iOS 6, we just add a class called ios6 to the body.

For detecting the standalone status, we use:

var standaloneClass = navigator.standalone ? 'standalone' : 'no-standalone';

Now we have the actual state in CSS. For hiding the address bar, the body should be 60px longer than the full viewport in iOS6 Safari. But we had used 100% for body height previously! Don’t panic. Just use this: {
    padding-bottom: 60px;

This gives a 60px space at the bottom. Now if the user would scroll down, the address bar would disappear. But we want it to happen automatically as soon as the app loads!

So here’s a pretty one-liner to append to anywhere you like.


Very cool, huh? Well, that additional 60px looks really bad. We have to cover up for it!

Now assuming you have a footer at the absolute (position: absolute) bottom (bottom: 0;), you can do this: footer {
    bottom: -60px;

That’s more like it. Now there’s a gap between the content and the footer! Never mind, just push the content further down: #content {
    bottom: 0;

That does it. We hid the address bar!

Standalone mode

Standalone mode is when a user adds your page to the home screen. It’s possible to hide the browser chrome there, so that would feel a lot more like a native app. First of all, you need to add the following in order to be able to hide Safari chrome in apps added to the home screen. This enables the standalone mode.

It comes with a few problems, though. First, the status bar is pitch black in iOS 7. Second, there are strange bars on top and bottom, as if you opened an old iOS app that doesn’t support 4-inch displays in a 4-inch device. Weird. To get rid of the bars, we have to add a second meta tag.

This tag is only valid for 4-inch devices. The strange thing is, you have to remove width=device-width this time!

Now, for the status bar. For consistency between iOS 6 and 7, we prefer to have a black-translucent status bar in standalone mode:

Having any value other than default fixes the black status bar issue, but again, for consistency, let’s stick with black-translucent.

It lets you use the whole display as a canvas, just like in iOS 7. So your actual content goes beneath the status bar and is visible there. For that reason, we need to leave a space for the status bar. Since its height is 20px, we just make the header taller and push the content further down.

.standalone header {
    padding-top: 20px;
    height: 80px;

.standalone #content {
    top: 80px;


Rubber-band scrolling on non-scrolling elements

Now, if you want to scroll in a scrolling element, there is no rubber-banding. But you can actually pull down the viewport if you start dragging on a non-scrolling element (like the header or the footer).

Now that’s also an imperfection we don’t want in our app. So we need to resort to JavaScript for preventing touch moves that happen in those elements. We’ll begin by listening touchstart events on the body. Whenever a touchstart occurs, we’ll immediately listen for a touchmove event to see if we need to prevent it. Just one touchmove event is enough to determine this, so we’ll unlisten the consequent touchmoves for performance reasons.

Now that we have a touchmove event on an element, we need to see if its as tall as its contents, or shorter. If the element is shorter than its contents, it means it should be scrolling, so we shouldn’t prevent the event. Keep in mind that our backs are safe with the previous simple solution, i.e., there won’t be a rubber-banding effect on scrolling elements.

But if it’s not shorter, than we should prevent the touchmove event so that it won’t trigger rubber-banding!

Keeping in mind that the DOM is a tree and there can be a lot of elements up that tree starting from the element we caught the event on, we need to traverse up the tree – up to body in fact (since we know that it shouldn’t scroll).

That’s about the whole story. Here’s the code.

document.body.addEventListener('touchstart', function() {
    document.body.addEventListener('touchmove', function moveListener(e) {
        document.body.removeEventListener('touchmove', moveListener);

        var el =;

        do {
            if (parseInt(window.getComputedStyle(el, null).height, 10) < el.scrollHeight)
        } while (el != document.body && el.parentElement != document.body && (el = el.parentElement));


There’s one problem with this approach, though. Sometimes you are just not careful enough, and you have some elements who are shorter than their contents but shouldn’t scroll, e.g. elements that act like they haveoverflow: visible. Now you can check against those elements in the code above, but I discourage it as it will have a performance impact. Plus, it prevents you from being cautious when writing CSS. Just write correct CSS; a container should, almost always, be at least as tall as its children.

Another feature of this approach – I recognize some might say it’s a problem – is that it completely disables the address bar. So the user cannot scroll it back down, either to refresh the site or change the URL to navigate away. Or, use the search box for searching for something in your app.

You can enable the address bar by letting the do-while loop reach the body, i.e., by removing the bodychecks in the while condition. I just have no use for the address bar in an app, so I prefer it this way.


So, that’s all about it! With the Baking Soda Paste, you don’t have to fear the rubber-banding ever again! Apply it thoroughly, rinse and repeat, and don’t forget to ping me back if you like it!

Wait! What about Android?

Sorry, I have little experience in the vast realm of browser quirks in Android. Some of the tricks here work for Android too, but I don’t have any device or the will to make it work for all Android devices. But your contributions are welcome!

OK, a quick tip about Android though.

If you want to go retina and resort to using 0.5 for initial-scale property, most Android environments will just show the app on a quarter of the screen. In those cases, just add a spoonful of target-densityDpi=320 to the meta tag and the problem will be solved. iOS ignores target-densityDpi setting, so you can just leave it there.


Amazon Promises Package Delivery By Drone: Is It for Real? - Okay, look. I know that the idea of having drones deliver stuff sounds like the future. And there are a lot of companies making promises about it, including, this weekend, Amazon. “We’ll be ready to enter commercial operations as soon as the necessary regulations are in place [in 2015],” Amazon says. The reason that Amazon can say this, and that it sounds so exciting, is that it is technically possible to put together a demo like the one they’ve just unveiled, where you have a drone autonomously transport an object from one place to another.


The software architecture time traveler

The software architecture time traveler - Would you like to go back in time and tell your younger self what to do to succeed and what perils to avoid?

This is what Tom Gilb did for me today.


On meritocracy

On meritocracy - Over 10 years ago I worked at company that prided itself on the fact that it was a meritocracy, and even at the time it seemed at best aspirational and at worst cringeworthy. Everyone knew that it wasn’t always true, and even companies with the best of intentions know it’s not completely true. Since that time I’ve travelled, lived in different countries, and worked for a large number of companies. At some point along the way I’ve come to appreciate that the reason why meritocracy was a lie was much more troublesome than I’d originally realised.


Black holes are ‘portals to other universes,’ according to new quantum results

Black holes are ‘portals to other universes,’ according to new quantum results - According to Albert Einstein’s theory of general relativity, black holes are uninhabitable chasms of space-time that end in a “singularity,” or a mass of infinite density. It’s a place so bleak that even the laws of physics break down there. But what if black holes aren’t so forbidding? What if they are instead some kind of intergalactic stargate, or maybe even a passageway into a whole other universe?

I always contemplated that physics and metaphysics would coincide and merge at some point. It’s not likely to happen soon, but this century is prone to new revelations about our understanding of the universe.


Brushing your teeth: no longer the best thing for your teeth - Here’s an article, via MicrobeWorld, that details very recent work published in Applied and Environmental Microbiology. The paper examines commensal microorganisms in the mouth, and the relative role they play in the formation of dental plaque. As we are probably well aware, the oral cavity is home to a vast number of microorganisms, a collection of prokaryotic and eukaryotic species. One bacterial species, Streptococcus mutans, is responsible for the process of tooth decay. S. mutans is a potent biofilm forming microorganism, and the presence of sucrose (table sugar) promotes the formation of the biofilm. When S. mutans acquires other sugars such as glucose and fructose, the growth of the organism produces lactic acid when it metabolizes the sugar. The acid produced as it grows causes the enamel of the teeth to be degraded. The combination of adhesion via plaque formation and acid production lead to the process of tooth decay, and the mechanical removal of plaque by brushing continues to be the most effective method for preventing dental caries.