Chrome apps … mind blown!

Don’t ask me how, but I’ve ended up in the Google Chrome Web Store, where I spent the last three hours – especially in the Productivity -> Developer Tools category.  I knew, there were plenty of apps to make Chrome OS / Chrome Browser super awesome, but it seems it’s been a while since I looked in there … My mind is officially blown!

I don’t need much from my Fedora laptop – a browser, a terminal, and some instant messaging apps.  But these days apparently that’s too much.  A lot of the things I do through the regular day can be handled right from the browser apps.

mysql

Here are some examples.

  1. Text editors.  There is a slew of them!  Simple and complex, specialized and generic, fast and … not so much.  Have a look at Caret for example.  It’s Sublime-like editor, based on the Ace editing component.  It offers a selection of themes, syntax highlighting for all the major languages, multiple tabs, project settings, and more!
  2. SSH client.  Yup, that’s right.  You can connect to your remote servers right out of the browser, using, for example, ServerAuditor.
  3. MySQL clients.  Choose between a simple command-line one, like MySQL Console.  Or a full-featured one, with ERDs and database browser, like Chrome MySQL Admin.
  4. Git, GitHub, and Gist tools.  Which there is a variety of…
  5. Web server (yes, really, a web server running in the web browser!) – Web Server fro Chrome, debugger (Xdebug), and compiler (Compiler.work).

Most of these offer session saving, networking synchronization, Google Drive data saving, social network integration, etc.

Wow!  The browser world has come a long way since Netscape 3 …

 

On the future of apps and mobile web

It’s been a while since I expressed my point of view on the apps and the mobile web.  (It hadn’t changed much though.)  While reading through the “Why Britain banned mobile apps” article, I caught myself nodding my head in agreement.

So why did the GDS ban apps? It wasn’t because they weren’t technically savvy enough to build them.

Cost, he says. Apps are “very expensive to produce, and they’re very very expensive to maintain because you have to keep updating them when there are software changes,” Terrett says. “I would say if you times that by 300, you’re suddenly talking about a huge team people and a ton of money to maintain that ecosystem”.

How did the UK reach an increasingly mobile population? Responsive websites, he replies. “For government services that we were providing, the web is a far far better way… and still works on mobile.”

Sites can adapt to any screen size, work on all devices, and are open to everyone to use regardless of their device. “If you believe in the open internet that will always win,” he says. And they’re much cheaper to maintain, he adds, because when an upgrade is required, only one platform needs recoding.

I think that the initial boom of mobile apps was caused by two major factors:

  1. Native applications had much better capabilities – user interface, performance, features, offline mode, etc – than their web counterparts.  Mobile browsers used to suck big time.
  2. The competition in the app market was much smaller than the competition for the “first page of Google”.

These two reasons were significant enough for a whole lot of people to go into the mobile application development.  So much so indeed that a whole new industry appeared.

But I never thought this would be permanent.  Unless, of course, there would be other reasons.  Which I don’t see.  And both of those reasons aren’t valid (to the most part) today.

Smartphones got smarter, stronger, and faster.  Mobile browsers improved a whole lot.  So unless you are doing something really pixel perfect or resource intensive (like some of the games), the mobile browser is more than enough for you.

And look at the competition in the app markets!  There’s like a hundred apps for whatever is that you want.  Endless lists of recommended, featured, and sponsored apps for ever growing list of app categories.  No matter what your app does – there are a few dozen of others that do the same exact thing.

If you absolutely definitely have to build a mobile app, don’t start with the native one straight away.  Do the hybrid one first.  Build a web application and package it into the native one with something like Apache Cordova.  This will save you tonnes and tonnes of time, money, and pulled out hair.  (I learned this the hard way!)

With all the hype mobile apps have generated in the last few years, they have some momentum.  They aren’t going to disappear.  But just because you can build one, doesn’t mean you should.  Build a web app.  It’s simpler, faster, and easier.  It scales better.  It works better (except for very few edge cases).  And it will cost you a fraction to support and maintain.

How cancer was created by the evolution

BBC has a rather lengthy article on how cancer was created by the evolution.  The gist of it is not very cheerful:

But a more telling reason for the rise is that humans, on average, live a lot longer than they used to. “If you live long enough you will get cancer,” says Biankin.

“If we decide that we all want to live to more than 70, then we have to accept that sooner or later we will get some sort of cancer,” says Bardelli. It is inevitable because our cells have not evolved to maintain their DNA for as long as we now live, he says.

However, there is some really amazing photography of cancer cells and the like.

CP695J Cancer cell scientific 3d illustration
CP695J Cancer cell scientific 3d illustration

RainLoop – simple, modern, and fast web-based email client

rainloop

For those of you who want something more than the classic-looking RoundCube, here’s the RainLoop – simple, modern, and fast web-based email client.  The feature list is very comparable, yet the interface is somewhat different, looking more like Gmail, than the Outlook Express.

National Cancer Institute on Cannabis and Cannabinoids

National Cancer Institute has an interesting update on cannabis … Basically, marijuana is not yet universally approved as a medical treatment for cancer (only in a few states for now), but quite a few large studies suggest that not only it’s not harmful, but quite helpful for both cancer treatment and post-treatment relief.

usa

I think this is a good step in the direction of “the world is not black and white”.  We’ve been tagging everything as just good or bad for way too long.  It’s time to start looking at benefits and side effects in a bit more detail.

WWW SQL Designer

www sql designer

I came across the WWW SQL Designer today, and I have only one thing to say…

Holy Molly!  I’ve been looking for a tool like this for a long long time!  It is a web-based database designer, which can export designs into MySQL.  It’s super easy to use and it does exactly what it is supposed to.  No non-sense.  Simply amazing!

Adobe Color CC – Color Schemes Tool

adobe color cc

If you are not a graphics or web designer by trade, but do have an occasional need for a color scheme that just works, Adobe Color CC is the tool just for you.  It’s web-based – so there is no need to install anything, it’s free, and it’s super easy to use.  It supports a variety of color rules – analogous, monochromatic, triad, complimentary, compound, and shades – just pick one, and drag the markers around the color circle, until you are happy.

I’ve seen and used a bunch of similar tools, but I think this one works the best of them all.

Deploying with git

Git is an excellent version control, but it’s more than just that.  A lot of people use it to deploy their projects as well.  Most suggestions (for example, this tutorial from Digital Ocean) around the web employ the post-commit (or other) hooks to push the code to a remote server.  While this works well, I prefer to do it differently.  I like the pull model better, where the deployment is triggered outside of git, and relies on git to fetch the code updates and run some sort of a build script, which handles database schema changes, cache resets, filesystem permissions, etc.  Such approach also allows to limit remote access to the servers (especially the production ones), and separate responsibilities of a developer and a deployer.

With the many pull, merge, fetch, and update options that git provides, it is sometimes difficult to choose what’s the right set of commands to use.  I’ve figured it out via a rather lengthy trial-and-error process.  But if you don’t want to go through all the pain of that, here’s a nice blog post that tells you exactly how to do that.  I’m copy-pasting the commands here just for the future reference.

cd "${DEPLOY_TREE}"
git fetch --all
git checkout --force "${TARGET}"
# Following two lines only required if you use submodules
git submodule sync
git submodule update --init --recursive
# Follow with actual deployment steps (run fabric/capistrano/make/etc)

And I suggest you read the full article for the explanation of why this is a better way and what are some of the issues with other strategies.