Author: Online Hut

IT

Mobile payments such as Apple Pay and Samsung Pay Cash are hot, but many consumers still prefer cash

A recent poll revealed that serious cybersecurity concerns are at the root of consumers’ confidence in mobile-only payments.

Sure, it’s quick and rewarding to simply sweep a smartphone under a scanner, and the popularity of payment options from Apple Pay, Samsung Pay Cash and Google Pay Mobile facilitate this at retailers worldwide. Despite the lure of living cashless, most people actually still want the option to pay with cash: 78% of consumers believe shops and restaurants should continue to accept cash, according to a recent J.D. Power “Pulse” survey.

As arcane as a loyalty to cash might feel to some, mobile payment and credit card providers have hurdles to overcome. While 85% of people over 60 years old believe that restaurants and stores should be required to accept cash, a whopping 72% of 18- to 29-year-olds concur (and 78% of that group still typically carry cash). In general, 82% of consumers carry cash, with a quarter of everyone polled (25%) generally keeping $50 or more in their wallet at any given time.

Despite the massive marketing push for mobile payments, the launch of cashless retail outlets (i.e. Amazon Go) and Apple’s latest launch into the world of credit cards with Apple Card, people are too preoccupied  with privacy and security to be 100% reliant on mobile payments. Another reason for the reluctance is concern for the impact that going cashless has on the unbanked, consumers without a bank account, mobile device, or credit card.

Americans are just not sold on the economy of the future. In fact, there are cities, Philadelphia and San Francisco, and states New Jersey, Massachusetts and Rhode Island, which put socioeconomic concerns at the forefront, and are in the process of enacting laws that actually require most businesses to accept cash. 

And consumers will use that cash to make purchases, as 67% of respondents used it to buy something during the past week (and 65% their younger counterparts, did, too). In fact, 61% used a debit card, 54% used a credit card, but only 20% of consumers say they used a mobile phone or smartwatch to make a purchase. When it comes to smaller purchases, 50% polled prefer cash to cards. The main reason people carry cash is in case of an emergency, with 60% of people saying this is why they still want to have money in their pocket. Small purchases are the reason 50% of people like to have cash on hand, while 42% carry cash for tips, and 20% use cash as a method to better manage finances.

By the way, grandma was right about that rainy day, because the No. 1 reason (60%) for carrying cash is “to have it in case of an emergency.”

Just as cybersecurity is at the top of IT concerns at the office, the same is true for consumers. Security breaches are commonplace and have become a reason for some people to not want to use credit cards. Cash doesn’t leave a digital footprint, so purchases are left out of the data sharing economy. 

The JD Power survey noted, “whether consumers are hoping to keep a tighter lid on their credit card information, or simply want to keep their purchases out of the data sharing ecosystem, cash can offer a technological work around.” Further, “keeping cash in the mainstream is a huge benefit to the underbanked community. For those consumers that either cannot afford or choose not to have smart phones, bank accounts, or lines of credit, a requirement to accept cash prevents building barriers to entry.” 

Perhaps in the future, but not in the immediate future, the benefits of cashless payments will outweigh the fears and unintended consequences of such a transition, from cash, to a mix of cash and cards, to a cashless society. A similar situation now exists with distance learning – check it out.

IT

The Book That Every Programmer Should Read

No, it’s not Knuth’s “The Art of Programming”. I’m talking about quite an easy-to-read (compared to TAoP) book, which, in fact, does not require any engineering or mathematical background from the reader.

I am talking about C. Petzold’s “CODE”. It is a truly remarkable book about how computers work. Let me explain why I think this book is so awesome.

The book starts from the very beginning, from explaining what code is, bringing several examples, like Morse code and Braille’s system. It then goes on to explain how electricity works and how it can be used to represent information with binary codes.

In later chapters, Boolean algebra is explained and the author shows us how to build basic components of circuits (logic gates) with battery, wires and simple relays. Those are used later to build an 8-bit adder circuit and a RAM array. Eventually, the author describes a computer with a simple instruction set and random-access memory.

This book is so amazing because it shows how simple principles can be combined to create the basis of the complex modern technology. You should read it to (at least approximately) understand what really goes on behind all the loops, pointers, variables, jumps and complex data structures. It won’t give you insights about the inner workings of Intel’s processors, but you will understand the basic things which make that pile of plastic and metal do math, display pretty moving pictures and download pr0n from the internets. Which is very important.

P.S.

During my second year at the university we were taught a course which was called “Computer Architecture”. What we really did during that course can be summarized as (painful) memorization of 8086′s instructions and writing a few programs in freaking Turbo Assembler (the year was 2008, by the way).

If only instead of all that crap we were taught what was written in Petzold’s book, it would’ve been one of the most useful courses ever, because:

  • It would really be about computer architecture and not about memorizing instructions or writing programs for a painfully outdated compiler;
  • I would actually learn something
IT

Assembler for DCPU16

I have implemented an assembler for DCPU16 in C++. It can be found here: https://github.com/10098/dcpu16. The assembler receives the source code from the standard input and writes the ROM to standard output. It supports labels too. To compile, you’ll need a C++ compiler with C++11 support. I was in a hurry, so the code is sort of slapped together with duct tape, but I hope to tidy it up a bit and add more features as Notch releases more specs.

A number of emulators are already available, I think I’ll pick one of them and extend it to support GUI for easier debugging.

UPD: Someone actually wrote an LLVM backend for DCPU16 – https://github.com/krasin/llvm-dcpu16, which pretty much renders all the assemblers obsolete, so I’m discontinuing this one.

IT

Brave Ball

It began in summer 2012, during a 12-hour layover in Moscow. After wandering around the airport for about an hour I got bored, so I broke out my laptop and started coding. I wanted to write something that had interactive graphics in it – I still remember how fun it was to follow NeHe’s tutorials years ago, and I wanted to re-capture that feeling.

Anyway, I ended up with a blob of messy C code that displayed a bunch of moving colored rectangles. I left it untouched for several months, but later I decided to come back to it and actually finish what I started. Ultimately I decided to rewrite it from scratch, this time using C++. So I tried to spend an hour or two after work writing code, drawing sprites and experimenting. If I actually worked every day, I’d finish in about a month, but actually the process took longer than that because I’m a lazy bastard.

The game has a sad excuse for a plot: the happy colorful world of Weird Little Creatures has been invaded by dark evil Meanies. You have to run and save all the defenseless younglings. Basically you just jump from platform to platform, avoid contact with the enemies and save the little creatures. In the end, there is an exit portal that you must step into.

I thought the game was pretty easy, but a couple of people I showed it to told me it was really hard. I don’t know, maybe I have played it so much that I got used to it. You can download it and see for yourself!

Some random stuff:

  • I used MS Visual Studio to write code, SDL/OpenGL for graphics, DevIL to load images, BASS to play sounds and music, mtPaint and GIMP to draw sprites.
  • I thought I’d eventually have to write collision detection between various geometric shapes, but it turns out you can do pretty well with rectangles too, if your art lends itself well to it.
  • You can actually draw sprites for your game, even if you’re not an artist. Just pick a simple visual style. I’ve never drawn sprites before, so I tried to have as little detail as possible, and compensate the lack of detail with motion, for example the antennae on the characters move, if the “protagonist” stops, it starts looking around, etc.
  • The mountains in the background are loaded from an image, but that image was generated procedurally (thanks to this great tutorial). Fractals can help you a great deal with creating art.
  • I rolled my own “packed file” format to store assets in a single file, but I’m probably going to use PhysFS in my next project.

The source code for the game (including assets) . I’m not particularly happy with the “engine”, but hey, it’s the first version. Anything you make for the first, and even second time, is gonna suck.

IT

C++11 Smart Pointers are Not Just For Memory


RAII is a useful idiom. It helps prevent resource leaks by making sure that resources are freed when they are no longer needed, and as such, provides a simple form of garbage collection.

The C++11 standard library provides a number of class templates (shared_ptr, unique_ptr, weak_ptr) to use this idiom for memory management.

However, memory is not the only resource that we have to manage. Sometimes we have to make sure a handle (e.g. a file descriptor, an OpenGL texture object, a HWND, etc.) returned by some library is freed properly.

There is a useful trick that allows you to use the standard smart pointer templates to manage such handles as well.

To accomplish this, we need to do two things:

  • Specify how the resource should be freed;
  • Make sure that internally, the smart pointer stores a handle, not a pointer

All smart pointer templates have an additional template parameter that allows us to specify a custom deleter type. A deleter type is basically just a class that has an overloaded operator() which accepts a pointer (or a handle, in our case), and frees the resource associated with it.

Let’s show this on a simple example. In this example, I’ll write a custom deleter for an OpenGL shader:

1 2 3 4 5 6 7struct ShaderDeleter{ void operator()(GLuint shader) { glDeleteShader(shader); }};

view rawgistfile1.cpp hosted with by GitHub We can then use it with a smart pointer to replace the default deleter:

1std::unique_ptr<GLuint, ShaderDeleter> smart_shader(glCreateShader());

view rawgistfile1.cpp hosted with by GitHub

But we’re not done yet. This unique_ptr will store a pointer to GLuint internally, but we really want it to just store a GLuint, our handle. So how do we accomplish that?

The internal “dumb” pointer of std::unique_ptr<T, D> doesn’t just have the type “T*”. Its type is std::unique_ptr<T,D>::pointer, which is defined by the standard to be std::remove_reference<D>::type::pointer, or, if such type does not exist, T*.

In other words, if you add a typedef named “pointer” to your custom deleter, it will be used by the smart pointer internally. So, to get the desired behavior we just have to do this:

1 2 3 4 5 6 7 8struct ShaderDeleter{ typedef GLuint pointer; // Note the added typedef void operator()(GLuint shader) { glDeleteShader(shader); }};

view rawgistfile1.cpp hosted with by GitHub So, now our trick works! We create a new OpenGL shader during initialization and it will be deleted once the smart pointer goes out of scope!

1std::unique_ptr<GLuint, ShaderDeleter> smart_shader(glCreateShader());

view rawgistfile1.cpp hosted with by GitHub

There still is one caveat. The indirection operator won’t work as expected with this pointer. Writing something like:

glAttachShader(p, *smart_shader);

yields a somewhat cryptic compilation error in Visual Studio 2012. You should use the get() member function instead, like so:

glAttachShader(p, smart_shader.get());

It’s pretty easy to understand why this is happening by taking a look at the implementation of operator* in unique_ptr:

It’s trying to apply the indirection operator to a GLuint. Clearly, this should fail.

So why does it work when we don’t invoke the indirection operator on the smart pointer? That’s because the compiler won’t even attempt to generate code for a non-virtual member function of a class template if it’s never used (this behavior is, in fact, enforced by the language standard). Incidentally, code for virtual member functions will ALWAYS be generated (I’ll let you figure out why :) )