Saturday, August 01, 2015

Is the OnePlus 2 really the 2016 Flagship Killer?

Making a recording of the VR launch, watching it several times, watching many review videos and articles about the NEW OnePlus 2 has left me thinking and wanting to post my own two cents. First, watch the VR launch (non-VR version) if you haven't:

Is the OnePlus 2 really the 2016 Flagship Killer?

The answer is both Yes AND No. Yes, because it has some of the top hardware you can get. No, because it doesn't live up to the hype.

The OnePlus 2 is a gorgeous phone. A premium-looking phone, touting the best of the best Snapdragon 810 v2.1 processor, a superb camera with laser autofocus, an alert slider that is something sorely missing in the Android world, and the fastest and most accurate fingerprint reader in the planet. And it runs Oxygen OS giving you the beautiful pure Android experience that Google has intended, with some added customization options to truly personalize your phone.

What OnePlus nailed:

OnePlus nailed it when it comes to several points about the OnePlus 2. Great specs. Thoughtful features. Vanilla Android experience. Fastest fingerprint unlocking. Building up the hype. A unique "first" with VR launch.

Where OnePlus flopped:

Didn't live up to the hype. First off the bat, is the VR Launch. Despite all the hype building up to it, it was really a disappointment. The content itself is was nothing close to being VR-worthy. As you can see from my video, just a regular video camera would have been more than adequate to provide the same launch in regular video format. It would have been a lot easier and so much better to make a LIVE YouTube event, than a pre-recorded VR-unworthy VR.

Carl at OnePlus really missed the great opportunity he had to really be creative with the whole VR experience thing. I'm not the most creative person in the world, but I bet I can come up with better ideas than following him around and looking at people talking endlessly about specs (more about that later):
  • Could have a fully 3D experience with a narrator's voice but no narrator or statically fixed narrator present. The 3D experience could be very immersive from all angles (or at least a few). The 3D world could take you inside a virtual model of the inside of the phone, have you look around and explore the features with the narrator (or look at wherever you want).
  • Could have a virtualized real world view of a city/landscape/virtual show event, in which several virtual features are augmented, and people can freely "walk" around and explore (yes Carl, you can "walk" around in a Cardboard world, without actually walking - there are VR games that do that). They could go to the stage and listen to the keynote (yes, a traditional stage keynote, on a virtual stage, with a seating plan for - get this - a theoretically infinite number of people). They could leave the stage and explore the surroundings. They could go pick up the phone from one of the booths with an infinite number of virtual OnePlus 2 phones in stock. They could explore the phone, or simply go to the booths and have virtual staff members show them the features on cue.
  • If it just had to be the tour of the office, it could have been immersive, with 4-6 people with "you" touring the office and interacting with Carl with interesting discussions. While Carl is yapping away about the specs, one of them could find something and say "check this out" and everyone would look there. You could be given a virtual phone to play with. The experience could have been spread to multiple angles at the same time. Activities like "look around and see if you can spot it" could be done.
  • At the least, could have been live, and with some sort of unique interaction (which is very difficult with a closed VR device, but at least the Cardboard provides a magnetic click switch) [PS: can't wait for Microsoft HoloLens!]

Instead, OnePlus basically recorded a traditional video tour script with a VR camera. And it is a pre-recorded 360 deg video playable any time, which is a disappointment because a lot of people was expecting a live event and kept alarms not to miss it. The only advantage to watching it right upon release was to get one of the invite codes before anyone else.

OnePlus thinks future-proofing means having a cover that can tell the phone to change the theme. This is not about the cover. The cover is a nice thing to have, but it doesn't really do anything except giving you the ability to change the look of the back. But OnePlus touted their vision of avoiding gimmicks, and then hypocritically slapped the StyleSwap gimmick on the face. But if future-proofing was really their goal, they would have made NFC and wireless charging an option. I understand that keeping costs low requires cutting back on features. But it doesn't mean those features couldn't be made available at an additional premium for those willing to pay for it. The StyleSwap covers could have easily been more than just a gimmick. The two metal contacts that the covers tell the phone what cover it is, could be used for so much more than just a simple cover ID. It could provide connection to an NFC radio built into an "NFC StyleSwap cover" or an "NFC stick-on radio" (that could go under the regular StyleSwap covers). It could provide wireless charging capabilities through a "Qi Charging cover" or "Qi Charging stick-on receiver".

I hope that they are keeping totally quiet about this to launch it as a big suprise to all on the New Year, with an OTA update and new NFC and Qi Charging StyleSwap covers to go with it. But then again, having absolutely no hint about these important future-proofing features in the plans makes me think they are just not interested in enabling it in the phone.

Onto the next point, in the VR launch, OnePlus talks a lot about specs, says "specs are boring", then talks some more about specs. Pretty much the entire VR launch was about specs. It starts off with Carl talking for far too long about his vision, then we meet with a group talking about specs, see a video of more people talking about specs, meet a guy (CEO) talking about his vision, see Carl say "specs are boring" then talk about the specs in a meeting room, see the Qualcomm guy talk about processor specs on a video conferencing TV (what's up with that? couldn't have made a cool floating video that Carl was looking at while walking instead?), then we see the trailer about the specs, then we meet the group again talking even more about specs, then we see Carl walk around talking about features, then he shows us the OS, then as though it was not told enough, Carl once again reminds us about the specs, finally wraps it up with the rollout details and the CEO fumbling to squeeze a talk about all the specs before the lights go out. I think I lost count how many times I mentioned specs there.

Where the critics are right:

 No NFC. No wireless charging. The 16GB storage in base model is too low.

The invite system keeps it difficult to get the phone. I'm still waiting for mine, and I'm at around 300,000 something in the queue. There are already more than a million in the reservation list.

Where the critics are WRONG:

"The invite system just shouldn't exist." It can and it adds value to the phone. It is understandable to have such a system as it builds up the hype and anticipation, and makes it a game. Getting the phone becomes a sweet cherishable memory after you had waited long for an invite, and looked far and wide to get one faster. You have WON the game, and you beat those who are still waiting. It's just not the same feeling if you walk up to the nearest store, pick a phone up, swipe your card and walk out.

Besides, OnePlus promises this time around, there will be a lot more invites and a lot more stock as the company has already been there and done that, and can now be bolder (not as cautious as it was with OnePlus One).

"Y U NO QI ME?" Wireless charging is OK to forgo because it's still a premium feature and not necessary for most people. The critics are all up in arms about this feature missing as though they cannot live without it. But to me, wireless charging is still a luxury that many people won't want. They wouldn't mind plugging in a cable (and often, they have to, as even with wireless charging at home or office, they still need to plug in occasionally when elsewhere). And it's even more pleasurable to plug the cable in with the new reversible USB type C port.

"Having no microSD slot is a dealbreaker." No, dear critics, it's not. If you as a manufacturer values the stability of your Android device, you won't want to have a microSD card slot in it. Google strongly recommends against having one because inferior cards often cause the phone to lag and even crash. Many flagship manufacturers agree and the latest flagships more often than not, do not have these slots because they want their product to be as stable as possible on their premium phone and reduce RMA-related resource wastage. They simply provide an adequate amount of storage to compensate. Which brings me to:

"The 16GB storage is a joke." No, it's a strategy. I'll tell you who else regularly employs this strategy where I live: ICE CREAM stores. Here's their pricing model that wouldn't make sense to you as a consumer, but makes perfect sense as far as profits are concerned: sell single scoop at $6, sell two scoops at $8.50, sell three scoops at $10. Can you see what's going on? A customer who initially wanted only a single scoop may be enticed to spend more by the pricing strategy used - it only costs $2.50 more to get another scoop... and look, it only costs $4 more to get TWO more scoops. OnePlus is being smart and doing this, because they want people to buy 64GB. If you notice, they only have a single scoop and a triple scoop offering. There's no double scoop. And the devices are priced closely. From a bottomline perspective, this makes sense because buyers who initially think they may only need 16GB would see it only costs $60 more to get an additional HUGE amount of storage (48GB) and be enticed to upgrade to 64GB (not everybody will do it, but many will). [Note that the ice cream is just an analogy, and analogies often have flaws. Don't flame me for it.]

"The display is only 1080p. We want Quad-HD." Seriously, WHY? What on earth are you going to do with a 4K resolution 5.5" screen? There comes a point where bigger stops being better, and many critics don't know when to stop asking for bigger. Did you know that OnePlus 2 has the exact same display specs as the iPhone 6 Plus. Same resolution, same diagonal size, same PPI (called Retina HD by Apple). If you looked at an iPhone 6 Plus and thought the display is crisp and gorgeous, it's gonna be the same when you look at OnePlus 2. There is really no need to ask for a bigger resolution (unless you're entering the tablet territory) because a 4K display would be a HUGE battery drain with no visual advantage. We can't already discern the pixels at the 401 ppi density unless we use a magnifying glass, so what are we going to do with 500 or 600 ppi displays?

Although, there is one avenue where a 4K or higher PPI resolution would help: VR. Because of the nature of VR headset design (like the Google Cardboard), the pixels are greatly enlarged, and while you can make out what's going on, the individual pixels are staring right at your face. A 4K resolution would give clearer images when the phone is used in a clip-on VR headset. But then, who uses their phone as a VR device everyday?

So, yes the OnePlus 2 can be a total Flagship Killer of the next year, if it is properly future-proofed with the addition of NFC and wireless charging. But even without the option to add them on, it's still a delectable phone to have at the price point.

What are you thoughts on the matter? Is the OnePlus 2 really the 2016 Flagship Killer?

BTW, did you know that OnePlus 2 equals 3?

Monday, July 27, 2015

Install a flat file blog in a subfolder in an existing Google App Engine website

 NOTICE:  This post is not very useful as a guide. It is documenting the failures I encountered trying to set up a flat file blog in a subfolder in GAE. Read for your pleasure, but don't try to follow it.

Google App Engine (GAE) allows you to set up a simple PHP website easily and for free with generous quotas - more than enough for a low traffic site. There are several guides on how to get one working. However, GAE works differently from traditional web hosting. Access is tightly controlled through app.yaml file; the static files and application files are separate from each other; and the application file system is not writable.

As WordPress requires a MySQL database (chargeable under Google Cloud SQL), I looked for a flat file blogging alternative.
  • Dropplets looks too simple and feature-poor. It doesn't have a comment system integration out-of-the-box, but Disqus can be added later. There is no rich text editor - plain text editing required in Markdown syntax. Google: 52,300 results
  • FlatPress looks too 90's and unattractive (sorry!). I'm sure you can build a modern look for it. It too doesn't have a ready comment system integration. No rich text editor - uses BBCode. Google: 252,000 results
  • HTMLy looks very promising and feature-rich while being simple. It's under very active development, and it's from South East Asia (Indonesia, to be precise). It doesn't look mature enough (began 2014). Google: 41,900 results
  • TextPress also looks promising, and it is mature (began 2012). The development has become less active as a result, and seems to mainly concentrate on bug fixes. This may be a more stable choice. Google: 312,000 results
  • PivotX supports both flat file and database, and it's very feature-rich to match. However, it looks like an overkill for a simple blog, with too much going on. Although open source, I couldn't find an online repository (like GitHub) for it. Google: 242,000 results
My requirement is to install the blog in a subfolder. Many blog installation tutorials do not cover subfolder installation, and assume the entire site is just the blog, and we will use the blog engine to maintain static pages (basically making it a CMS). However, my use case is different and I don't want that.

Also, since GAE prevents application from writing, I want a blogging platform that can tolerate not being to able to write in the server. HTMLy and TextPress 2.0 have caching system, but this can be disabled easily. What I plan to do is to run a local instance, compose posts, then deploy the changes into GAE.
TIP: Don't just test locally when developing in App Engine SDK. Things that work fine in local environment can break when deployed, and I had been hit in the head by this several times. Always do a test deployment first. Now I use a separate version: test copy where all changes are made and tested locally, then deployed and tested again in the test instance online. Once everything is working fine, then the changes are synced to production version's local copy and deployed to GAE production version.

Before we begin

To add posts and do other things in our blog admin panel, we need to be able to write to the file system. Since the SDK simulates a readonly file system locally, a configuration change is necessary to disable the simulation and set up the blog. Add the following configuration to php.ini file (create one if you don't have, next to app.yaml).

google_app_engine.disable_readonly_filesystem = 1

 NOTICE:  This post is not very useful as a guide. It is documenting the failures I encountered trying to set up a flat file blog in a subfolder in GAE. Read for your pleasure, but don't try to follow it.


HTMLy looked very promising as it's touted to be light, and it looks feature-rich. The readme does indicate the server file system should be writeable, and a cache is maintained. (I have not looked into disabling the cache.)

Obtain the latest release. You can get the ZIP file and extract, but since GAE SDK has OpenSSL extension in PHP, you can use the installer.php instead.

If you use installer.php, put this file in a subfolder called "blog". Add the following handler in app.yaml.
- url: /blog/installer
  script: blog/installer.php

Run the local instance and go to http://localhost:9081/blog/installer (your port may be different). Follow the wizard to set up the initial configuration of your blog. It will be installed in the subfolder "blog" and installer.php will self-destruct after redirecting you to http://localhost/blog/add/post.

Normally, you should get the add post page from the above redirect, but you will get a blank page in the GAE SDK. This is because we don't have a configuration for the URL in app.yaml. Also it is because the port was removed from the URL. Change the handler you had added earlier to the following (we don't need the original handler any more):

- url: /blog/system
  static_dir: blog/system
  application_readable: true

- url: /blog/themes
  static_dir: blog/themes
  application_readable: true

- url: /blog/.*
  script: blog/index.php

You will also need to change the value of site.url in the file blog/config/config.ini to the following (according to your subfolder name). This is to avoid locking the blog HTML into a particular domain and making it act relative to any domain.
site.url = "/blog/"

Now, navigate to http://localhost:9081/blog/ (adding the port back to the redirect URL).

At this point, I gave up as the blog does not work well with GAE restrictions. There are a lot of weird PHP warnings and errors, image upload failed, and the blog does not show my posts despite saving the .md files for them. If you can figure out how to fix them, please post a comment.

Moving on...

TextPress 2.0

TextPress 2.0 require a writeable file system by default as pages are not generated on the fly but cached. This can be changed to make TextPress work with GAE.

Download TextPress latest version. Extract it into the "blog" subfolder.

Set up handlers in app.yaml as follows:

- url: /blog/themes
  static_dir: blog/themes
  application_readable: true

- url: /blog/vendor
  static_dir: blog/vendor
  application_readable: true

- url: /blog/.*
  script: blog/index.php

Change three lines in the configuration in config/config.php as follows

    'site.baseurl'      => '/blog',   // Site URL (Global)
    'assets.prefix'     => '/blog', // prefix to be added with assets files
    'cache' => array(
        'enabled'   => false, // Enable/Disable cache

Start GAE SDK local instance and visit http://localhost:9081/blog/ (note that your port number may be different).

Unfortunately this is where the fun died. TextPress 2 was easier to set up than HTMLy and worked fine without spitting out PHP warning and errors. It even stayed clean without caching or trying to write a bunch of files. It showed all the sample article titles.

BUT: It wouldn't load the actual content of the sample articles, the links are broken. The config is confusing, and the download itself is messy with all the .DS_Store files and different versions from the GitHub version. There was also no admin configuration - it looks like the posts have to be manually added as text files.

Moving on...


Extract. Edit app.yaml:

- url: /blog/images
  static_dir: blog/images
  application_readable: true

- url: /blog/pivotx
  static_dir: blog/pivotx
  application_readable: true

- url: /blog/.*
  script: blog/index.php
  #script: blog/pivotx/render.php # second try

Go to site.

Nothing happens - downloads "index.php" (not sure from where). Complete failure. Tried different app.yaml - now website keeps redirecting.


Extract. Edit app.yaml:

- url: /blog/(.*\.(css|gif|ico|jpg|js|png))$
  static_files: blog/\1
  upload: blog/.*\.(css|gif|ico|jpg|js|png)$

- url: /blog/?
  script: blog/index.php

- url: /blog/(.*)\.php$
  script: blog/\1.php

- url: /blog/(.*)
  script: blog/\1.php

Tip: By this point I figured out it's better to use static_files instead of static_dir to only open up the actual static resources rather than the entire directory contents. I should probably have done the same for previous attempts.
Go to site.

Blank page on navigating to blog/setup.php. Complete failure. Unable to determine cause due to unhelpful error message.


Extract. Edit app.yaml:

- url: /blog/(.*\.(css|eot|jpg|js|json|png|svg|ttf|woff))$
  static_files: blog/\1
  upload: blog/.*\.(css|eot|jpg|js|json|png|svg|ttf|woff)$

- url: /blog
  script: blog/redirect.php

- url: /blog/
  script: blog/index.php

- url: /blog/(.*)\.php$
  script: blog/\1.php

- url: /blog/(.*)
  script: blog/mod_rewrite.php

Also add mod_rewrite.php (change 'q' to 'filename') and redirect.php:

header("Location: blog/");

Go to site.

Kind of worked. The blog-site fluidity appeared broken. Completely broke upon choosing a different template. No error message. Found this to be very light though, at just 238 KB (after deleting the unexplained dropplets.json file).


I have had the most success with TextPress 2, followed by HTMLy (which required a bit more of hacking), then by Dropplets. With FlatPress and PivotX I experienced complete failures.

I am thinking of forking either Dropplets (due to its simple code structure) or TextPress 2 (due to its higher success rate) and cleaning it up to work properly with a GAE-deployed multi-domain subfolder blog (ideally without ever knowing in advance which subfolder or domain it is in).

Or perhaps, Ghost with Node.js ... ?

Saturday, July 18, 2015

Disable auto save in JetBrains IDE software (IntelliJ IDEA, PyCharm, PhpStorm)

JetBrains provides the following IDE software:
  • IntelliJ IDEA
  • PhpStorm
  • PyCharm
  • RubyMine
  • WebStorm
  • AppCode
  • CLion
Google also provides Android Studio which is powered by the IntelliJ platform.

If you come from a different IDE such as Eclipse, you will be unpleasantly surprised to find that JetBrains-branded IDEs automatically save everything the moment you look away. The proponents argue that as you work on your project, you should not have to worry about saving files. But to others, this auto-save behavior which is enabled by default is a curse that catches them by surprise, and a shocking departure from the workflow they are very much used to.

You can change the behavior by altering some settings. After the change:
  • Modifications are no longer automatically saved when you're just editing.
  • They are saved when you press Ctrl+S.
  • They are saved when you build, compile or run.
  • Refactoring that affect files that are not open are still automatically saved without opening those files.

But first, some caveats:
  • There is no Save for individual tabs. The shortcut Ctrl+S is for "Save All" which will save all modified tabs/files. Be careful and remember this.
  • The "modified" indicator on the tab is slightly different. Instead of something obvious like a real asterisk next to the file name or a color change, the indicator is a subtle asterisk image that appears on top of the file icon (in the tab bar). You may have to look a bit longer at the tab to notice it.
  • Closing a tab with a modified file will not ask you whether to save or discard the changes. Instead the file is maintained in "Local History" in a modified state. When you open the file again, your changes (along with undo-redo history) are retrieved from the Local History. The actual file itself is not saved with your modifications.
  • There is no option to revert changes to the state of file on disk in the IDE user interface.
    • You can force a revert quickly by touching the file (or simply editing it insignificantly in an external editor and saving it) and then switching to the IDE. It will prompt how to resolve the conflict, on which you can select "Load File System Changes".
    • You can also undo your edits until the asterisk disappears, or revert to an older revision in VCS > Local History. (Note that "File > Synchronize" option acts similar to "Save All" and is not a way to revert.)
How to disable auto-save:
  1. Go to File > Settings (Ctrl+Alt+S).
  2. Go to Appearance & Behavior > System Settings.
  3. Make sure the two are unchecked:
    • Save files on frame deactivation
    • Save files automatically if application is idle for x sec.
  4. Go to Editor > General > Editor Tabs
  5. Put a checkmark on "Mark modified files with asterisk"
  6. (Optional but recommended) Under "Tab Closing Policy", select "Close non-modified files first". You may also want to increase the number of allowed tabs.
  7. Click Apply > OK.
That's it.

JetBrains IDEs are built around the idea that workflows should be centered around a VCS (version control system) where files are logical abstractions of changes, and that VCS should not be an afterthought as it is in the kind of workflows we are used to in other IDEs and programs - manually saving changes to a file in disk, then separately committing changes to VCS. Thus the IDEs come with instant auto-save and a built-in VCS called "Local History".

However, many of us are not used to this kind of behavior and would want to retain our workflows centered around manually saving edits to a file in disk. Though unfortunately JetBrains IDEs don't allow us to truly revert to such a workflow (see caveats), at least we can come close with the above setting changes.

Friday, April 03, 2015

WhatsApp voice call feature bans regular mobile network calls

With the recent introduction of WhatsApp voice call feature for their Android users (without requiring an invite from one of your friends who have the feature), the WhatsApp client has outright banned the use of regular mobile network to make calls through the app's interface. The WhatsApp developer team (now under Facebook) has decided to make it simply impossible to do what you used to be able to do in their Android client.

Many users have found it very handy to place regular calls to their WhatsApp friends through the app's interface, but with this change, they are forced to take the longer route of going to their home screen, opening the phonebook/contacts list, finding the contact and making a regular call. Or perhaps the slightly better (provided you know about it) but still longer route of opening the "Contact info" screen in WhatsApp, choosing "View in address book" in the menu and making a regular call.

Before the free calls were introduced, WhatsApp allowed making a regular phone call by simply selecting "Call" in the WhatsApp conversation menu. But with the free calls introduced, that option is no longer available, even when it makes sense to make it available.

There are many instances where making regulars calls would be handy.
  • The contact doesn't have an up-to-date WhatsApp client or is using an iPhone.
    • In this case WhatsApp simply complains the contact needs to update the app to receive WhatsApp calls but the message has no option to make a regular call instead!
  • The contact no longer has an active data connection or one of the data connections required is currently switched off.
    • In this case WhatsApp simply calls the contact anyway and then just ends the calls.
    • If your friend doesn't have a data connection, there's no notification whatsoever about the lack of data connection, let alone an option to make a regular call. This can be confusing to you as it appears that your friend's phone is ringing and your friend is ignoring you, when in reality your friend's phone is unreachable (regular network call distinguishes the two but in WhatsApp call they behave the same way).
    • If you don't have a data connection, there's a notification about the lack of data connection (after the app stupidly attempts making a call that requires data), but the message has no option to make a regular call instead.
  • The contact is not using WhatsApp temporarily or permanently.
    • This is a less likely scenario but can happen when the contact switched to a spare phone with no WhatsApp.
I have made a call using the WhatsApp voice call feature, and the quality is not as good as, say Google Hangouts, and definitely not near the regular call quality. I think this all-out ban on regular call in the app is unjustified when the feature requires data and latest client, and especially when the quality is bad. The ability to make a regular call should have been an alternative option.

The feature was released without much thought and is not as polished as it should be. Instead of working in conjunction and cooperation with the regular mobile calls, it attempts to replace regular calls completely and does so in a terrible way.

This ban is coming soon for Apple iPhone users who are still "stuck" with regular calls placed over mobile networks in their current WhatsApp clients for iOS.


Related Posts with Thumbnails