P2P+cloud

A few days ago I was thinking that it’s really a pity that I cannot find a good iOS shopping list app in my language. Good means simple, allowing me to manage multiple named lists with check-completable items, with autocompletion on typing product names (using a built-in but adaptable list of names), and syncing to my wife’s device.

For now I use Apple’s Notes app which has everything except autocompletion. But it does sync through cloud, and there I also have other notes, not just shopping lists. It would be nice to have domain separation.

So let’s assume that I want to develop such an app. My deep question here is how should it sync data between devices?

  • Through cloud: should I just go with the traditional way, i.e. having a server API and database in the cloud to provide data to client app instances, and then syncing will be done through that central repository? or
  • Through peer-to-peer (P2P) connections: directly between devices when they are on the same network.
  • Or both? I.e. try P2P first, then cloud? (With some clever way to send messages similarly, even if P2P communication relies on different protocols than Web?)
  • Or configurable by end users? So that if I have an important list that I don’t like to be stored in cloud, but I would accept it being on my wife’s device, I could configure that only P2P is enabled.

Thinking about these issues, I found this article, about P2P-ing the entire Web. Very, very interesting. That would turn actually all the four points above into a single one, ain’t it?… (But we would need to change core protocols for that to work as in P2P communication at any given time one device is a server, i.e. accessible through an IP address, and we all know client machines are usually behind routers, firewalls and generally out of reach.)

Advertisements
Posted in Miscellaneous | Tagged , | 1 Comment

Next wave?

First and second steps

At first there were desktop computers:

  • either at home or at the office (later also on the go with notebooks),
  • desktop apps present complex information in 2D (or projected 3D) graphical format on a large screen, with sound, and
  • users can input data and commands with a mouse and a keyboard, that they initially need to learn how to use.

Then we had the smartphone revolution:

  • everywhere, even on the road,
  • as powerful computing components got small enough,
  • mobile apps can show fair amounts of information also in 2D format on a small screen (later also larger “tablets”), with sound, and
  • users can easily input data and commands with natural multi-touch gestures (and lately, also voice),
  • while they can continue using their desktop computers whenever mobile devices do not support certain features or scenarios (such as for development).

Third leap?

One can think about the roadmap of Amazon Alexa and similar voice-enabled devices:

  • either at home or at the office (later probably also in vehicles),
  • with help from artificial intelligence development,
  • voice apps can provide information in sound format using human language even without a screen (later probably in more languages, and with optional touch screen accompaniment), and
  • users can input a fair amount of commands naturally with their voice (and optionally some touch gestures),
  • while they can continue using their desktop computers and smartphones whenever voice-enabled devices do not support certain features or scenarios or when they are not around,
  • but unless people want to get away from smartphones themselves (like the roadmap article linked above suggests) – something that isn’t possible when they are on the road without a vehicle (I guess) – there is little actual need for these devices since smartphones can easily turn into voice-enabled devices anyway.

Finally, we have Microsoft HoloLens and similar devices of the future:

  • everywhere, even on the road,
  • as powerful computing components get even smaller, and with help from artificial intelligence development,
  • holographic apps would present very complex information in 2D and natural 3D augmented reality format directly projected on eyes, with sound, and
  • users can input a fair amount of commands naturally with air gestures and their voice, and textual data and more commands with a Bluetooth connected keyboard,
  • so they could eventually get rid of their smartphones and later even their desktop computers,
  • but the device needs to become more powerful, yet lighter and comfortable enough for end users, foldable to fit into pockets, and also get highly improved battery life (technically difficult), and end users need time to get used to wearing such glasses instead of touching phones (which would be very difficult too, I guess), and supplementary, air gestures may turn out as being just too difficult to be performed all the time by people, compared to using multi-touch screens in this regard.

As you can see, the final points of both possible directions indicated above are fairly big, so I don’t think a truly revolutionary wave 3 is going to happen soon, myself. Instead, I tend to consider these devices as interesting accessories, maybe even opening new niche markets that developers can embrace (just like smartwatches), but not more for now.

Posted in Miscellaneous | Tagged , , , , , , , | Leave a comment

Flutter

I recently found out about the new cross-platform framework for mobile development that Google backs up: Flutter. Although it’s only in alpha stage (i.e. early development) at this time, I wonder, could it eventually reach more adopters than Xamarin or Cordova-based frameworks, or – more importantly – more than native mobile development?

Here is the table I came up with to compare:

Android + iOS
native
Cordova-based cross-platform Xamarin
cross-platform
Flutter (alpha)
cross-platform
Backed up by Google + Apple Apache Microsoft Google
What you need to know/learn? Java/Kotlin + ObjC/Swift JavaScript / TypeScript C# Dart
How does it work? Natively WebView: interpreted code, rendered as in device browser AOT-compiled, uses OEM widgets, native rendering AOT-compiled, uses custom widgets, custom rendering
Stock-like UI? Yes Yes Yes Requires custom widget selection
Native performance? Yes No Yes Yes
Easy maintenance? No Yes Yes Yes
Difficult corner cases? No Yes Yes Yes
Easily access new OS features? Immediately Later Later Later
Non-mobile platform support None Web Windows None
3D support Unity WebGL None None

While I still don’t know the answer, I tend to say it’s a no.

Unless Flutter would prove to have support for many use case scenarios and very few bugs when it would go beta, which I assume will be very difficult given the fact that they do custom rendering and that developers can only use widgets from a custom catalog.

Or unless Google pushes it hard into Android Studio and “forces” everyone (or at least most Android developers) to use it, like Microsoft did with Visual Studio .NET when they wanted less Win32 development long time ago. But this time it’s different, as we have a mobile OS duopoly and Apple iOS developers could simply stick with xCode anyway!

By the way, Android Studio 3 is now live, with Kotlin language support!

Posted in Architecture | Tagged , , , , , | Leave a comment

Learning the basics of programming can and should be fun

Myself I have learned the basics of programming using GW-Basic back in early 1990s. Once I understood what programming really is – i.e. that i = i + 1 actually means incrementing value of variable i from the computer’s memory and not a mathematical equality – that simple interpreter program running on DOS became my best friend.

(Since I didn’t have access to a PC every day back then, I actually used to have a notebook where I was writing programs down whenever ideas came, eventually checking them with GW-Basic only later, but as soon as I got a chance.)

And as I recently tweeted, I found out that there is a very easy – and 100% free – way to run a similar, compatible interpreter on Windows, Mac, or Linux: PC-Basic, which – together with reading some documentation or following some Basic tutorials – can help you or your children to at least check what programming is about if not more!

Note that if you think that Basic is a dead programming language nowadays you’re totally wrong. Actually we have Visual Basic that can and is used in the .NET world within comtemporary projects, but – most importantly – even if you’d need to learn something completely new later:

The concepts that you’d understand through Basic will remain the same regardless of the platform you’d eventually need to develop for: you’d just need to build more knowledge and skills on top of the common core!

C++, Java, .NET, Swift, and many other fancy languages and frameworks rely – at their bottom – on the same computing infrastructure, made of:

  • instructions (such as assignments, aritmetic operations, performing loops, and decisional branches) to be executed at runtime;
  • memory variables holding different types of values while your programs run;
  • and controlling input and output to support communication with end users.

Sure, the newer technologies come with add-ons like object orientation, events, and so on, but it will be easy to learn about these enhancements once you master statements, variables and simple user interface handling that you can do with Basic alone.

And unlike when using an IDE, learning programming with an interpreter program is – in my opinion – a lot more fun, as you don’t feel alone since you are… talking to a bot!

Posted in Miscellaneous | Tagged , , , , , | 2 Comments

Swift selectors and number of arguments

In Swift, you can create and “perform” a #selector like below (e.g. in an iOS app) and it seems to work just fine (i.e. executes the “selected” function):

class Obj1 : NSObject {
    var value: String?
    @objc func setValue(value: String) -> Void {
        self.value = value
    }
    func run() -> Void {
        let selected = #selector(setValue(value:))
        perform(selected, with: "V")
        print(value!)
    }
}
Obj1().run() //outputs: "V"

Then you can add a new argument to the function definition like this, and running it through the selector would still work if you just add a second with argument to the perform call as well:

class Obj2 : NSObject {
    var value: String?
    @objc func setValue(value: String, suffix: String) -> Void {
        self.value = value + suffix
    }
    func run() -> Void {
        let selected = #selector(setValue(value:suffix:))
        perform(selected, with: "V", with "s")
        print(value!)
    }
}
Obj2().run() //outputs: "Vs"

But unfortunately you cannot follow the same pattern and add a third argument to setValue, expecting to be able to add another with – the code below doesn’t compile because there is no appropriate perform override available on NSObject – although the #selector expression itself would run correctly:

class Obj3 : NSObject {
    var value: String?
    @objc func setValue(
        prefix: String, value: String, suffix: String) -> Void {
            self.value = prefix + value + suffix
    }
    func run() -> Void {
        let selected = #selector(setValue(prefix:value:suffix:))
        perform(selected, with: "p", with: "V", with "s")
        print(value!)
    }
}
Obj3().run() //expected output: "pVs"; but Obj3 doesn't compile!

I assume this is mostly because such a construct would be rarely needed, so extending the library with more overrides would have just been too much overhead. Moreover, I understand that it is eventually possible to do it in a generic way by calling some lower level, Objective C library, functions. But I think it’s good to acknowledge this NSObject inheriting limitation (or should we call it inconsistence?) rather sooner than later.

Of course, if your selected function doesn’t have any argument, executing it with a selector would still work, just don’t pass any with argument to the perform call either. (Awkward conclusion: the approach works only with functions that have 0-2 arguments.)

Posted in iOS, macOS, Swift | Tagged , , , , , | Leave a comment

Avoid extracting internal libraries

In a not-too-small software development company it’s very likely that you’ll manage multiple projects over time, with multiple teams and doing work for multiple customers. And for each platform/framework that you’d target (sometimes even cross-platform) you will probably determine that you could extract and reuse common components from code written by your developers in multiple ways:

  1. By extracting common components inside an application only, to better organize and maintain code for that specific project;
  2. Packaging some components to be reused by the same team and/or other teams in the company, for the same and/or other customers/partners;
  3. Publishing generic components as separate products that you could either sell or give for free to other developers too, with or without opening the source code.

I totally agree that points 1 and 3 are very good choices.

However, I think that packaging some components and distributing them only internally in your company, especially if this is done to be reused by other teams, is not a good approach, and this is for two simple reasons:

  • When you share code internally only, you tend to document it poorly, if you do it at all. Moreover, although for developers the code is the best documentation of itself, sometimes it’s difficult for colleagues to reach the original source code of such internal components or it would require asking many questions and obtaining appropriate rights to get to it;
  • When you share code internally in a company, you must ensure that the colleagues who could use it – including the newly hired developers from your and other teams – would know about what’s available and how to use the extracted common components correctly; as at first they only have knowledge and skills for the core platform(s)/framework(s) that your components rely on too, you’ll need to train them well before they could do work on top of the super-framework solution.

What to do then? You cannot just let all teams in your company to rewrite the common things (like a generic .NET unit of work/repository pattern implementation, for example) all the time, can you?

I’d say, why not? If the customers pay separately, then it’s fine – because each implementation will probably have something specific that will fit better for the needs of the customer who requested it or those of the project that it is reimplemented for!

And if you still say it’s not OK, then just go with point 3 instead, and extract a separate product out of the common code – a generic component library – that other developers could download and for which you’ll surely prepare good documentation, usage samples, and better overall quality. Of course, if legal agreements require it, talk to your customer(s) to allow you to extract, publish/sell that library separately, providing some of the outcome to the customer(s) themselves if the cost is shared as well!

Posted in Architecture | Tagged , , , | Leave a comment

What to do in IT

You’ve studied computer sciences, and you’re good at it. How do you select your job?

Assuming that you don’t want to be a researcher (but up to a point even if you do), and that you like software development, you can use the sheet published in this previous post to find the right place for you. Of course, some of these technologies may look obsolete, others too platform-specific, but use the sheet just to select an abstraction degree:

Technology

Nowadays, I think the best shots you have are these:

  • mobile (iOS/Android+WebAPI): easy path, high productivity, not requiring maths/physics; you’ll be able to get customers soon as everyone has a smartphone;
  • augmented reality: may require 3D maths/frameworks, oriented towards the near future; some AR apps may already run on devices today (HoloLens, ARKit, ARCore);
  • artificial intelligence: business oriented projects on core AI topics have started to appear and on such a topic you’d get a chance to work on something difficult, while integration of existing services is already possible (Microsoft, AppleGoogle);
  • quantum computing: this seem the most advanced thing you can work on today; but it would require very good maths/physics knowledge and skills because the technology has not yet reached a point where you could abstract away the details.
Posted in Miscellaneous | Tagged , , , , | Leave a comment