Skip to Content

In this post I look at how the editor environments that we come across in our daily work are different, and, as those differences might grow and expand as we become cloud native, how we bridge the contrast in facilities with core obsessions such as correct indentation and whitespace. 

This weekend I continued to look into Kubeless, a serverless framework that is native to Kubernetes. Kubernetes allows you to automate deployment, scaling, and management of containerized applications – in other words, to orchestrate units of computing across places where containers run, on your workstation as well as in the cloud.

Serverless computing

At the heart of serverless computing is the concept of a function, usually stateless and short-lived, the loading and execution of which is taken care of for you. Functions-as-a-Service, or FaaS, is another term for serverless. Of course, serverless is somewhat of a misnomer, as there are definitely servers involved, but the point is that you don’t have to worry about that. I’m a fan of serverless computing, having dabbled already with the Google Cloud Functions flavour of serverless, in experiments to create conversational actions for the Google Assistant framework (see “Google Cloud Functions + Sheets + Apps Script + Actions On Google = WIN“) and more recently in my discovery of the SAP Cloud Platform (SCP) Workflow service (see “Discovering SCP Workflow – Service Proxy“).

Anyway, I digress. Mostly. But what triggered these thoughts was the availability of a UI for Kubeless, which looks like this:

(The Kubeless UI, from the Kubeless UI Github page)

 

YAEE (Yet Another Editor Environment)*

I found myself inside this Kubeless UI editor environment over the weekend, on my local Kubernetes environment via Minikube. This environment is not required to build serverless functions, but makes the process a little more comfortable.

* The term and acronym “Yet Another …” comes from the Perl community, where there’s the “JAPH” acronym, (Just Another Perl Hacker), originated and popularised by Randal Schwartz, and the “YAPC” acronym (Yet Another Perl Conference).

The editor is basic, and arguably only one of the key components of the environment. But a basic editor here is perhaps “good enough”, because of the nature of what you’re going to be writing – a fairly simple function that does one thing, and one thing well. Rather like the Unix philosophy where you have a pipeline of commands that also each do one thing and do it well. But that’s a story for another time, perhaps.

Editing short sections of code like this reminds me of the script task concept within the SCP Workflow service (see “Discovering SCP Workflow – Script Tasks“). There too we have a (usually) short piece of code, which is almost secondary to the bigger picture of the overall workflow definition itself. Yes, the editing experience is provided by the SAP Web IDE, which offers many facilities, but for me the mindset of writing “helper” scripts here keeps me mindful of the overall end goal (to create a clear and efficient workflow experience) which is in contrast to the scripts themselves which are more a means to an end.

Moreover, the fact that at the time of writing, only ES5 JavaScript is supported, preventing me from indulging in fat arrow syntax and other ES6 goodies like generators. This in turn holds me back slightly from “over committing”, in the sense that “support for something better (ES6) will come along soon so I’ll just tread water for now”. The same situation can be found in Google Apps Script, where there’s also only support for ES5, and where I find myself writing a lot of “helper” code.

So already that’s three editor environments we’ve talked about – in Kubeless UI, SAP Web IDE, and the Google Apps Script editor. That’s on top of any “main” editor environment, which for me (beyond SAP Web IDE for many things) can be either vim on a remote virtual machine or the Google Cloud Shell editor.

(The Google Cloud Shell editor, from the Google Cloud Shell code editor feature description page)

And of course there’s the ABAP editing environments SE24 (sorry, I mean SE80) as well as the Eclipse-based ABAP Developer Tools in the form of ABAP in Eclipse. Add to that the countless online REPLs (see “Monday morning thoughts: cloud native“).

Further, think of the wonderful Jupyter Notebook cloud literate programming environment, which is also being used, coincidentally, in SAP contexts – see the “Use Jupyter Notebook with SAP HANA, express edition” tutorial, for example.

(Part of a Jupyter Notebook, from the jupyter.org website)

Here too, the code editor facilities themselves are secondary to the overall (amazing) experience of the notebook concept, and the amount of code you write in any one section is small.

And it would be remiss of me not to mention the Chrome Developer Tools themselves, which provide a common editing environment, especially when you link to your local filesystem for persistent edits.

The key commonality is difference

That’s a lot of different editor environments – and apart from Eclipse, I haven’t mentioned any traditional workstation-local tools such as Atom, Sublime or the editor-du-jour VS-Code (which I also enjoy using). Not only is that a wide range of editors, but also a wide range of contexts, or programmer mindsets, when using these different environments. I’ve already alluded to the mindset example when writing a Workflow service script task. When using a Jupyter notebook one might be thinking in a more literate programming style. When writing a cloud function one might be thinking of the strict interface and ensuring things remain quick and stateless.

What’s common though across all these mindsets, at least to most people, it would seem, is the implicit requirement to impose decent formatting on oneself and one’s code. Proper use of whitespace (whether you’re a tabs or a spaces person, that doesn’t matter) and correct – or at least meaningful – indentation. Indentation which is in some cases (Python) a requirement, rather than something nice to have.

What’s also common is the fact that because you’re editing in different environments, it’s likely that some of them won’t have the creature comforts we’ve come to expect from “core” editing environments such as SAP Web IDE, VS-Code or Eclipse. I’m thinking particularly about a couple of features: the ability to customise the editor’s look and feel (and also how it fits into the wider continuous integration story at your workplace), and tools such as reformatters.

Formatting poll

Last night I set up a poll on Twitter: “when writing a quick-n-dirty or hacky program, do you still care about whitespace & indentation or not?”:

The overwhelming response so far is that people care. I have already had some great responses, from the strong words from Jelena Perfiljeva to versions of an editor-feature solution from Uwe Fetzer , Wouter LemaireYuval Morad and others (format-on-save or a format hotkey).

Yes, the editor-feature solutions are great, but only when we’re working in that specific editor. When we move across different editing environments in our daily work, which will be a scenario that only happens more often as we move to the cloud, we’ll come across editing environment like the examples mentioned earlier, where such features are either not present, or at least hard-coded to format in a way you don’t particularly like. So I found myself manually editing and correcting whitespace in my hacky script yesterday not because there wasn’t a formatting feature in the editor in which I was writing the code, but because I’ve become so used to the “lowest common denominator” (of no format feature) that I naturally turned to doing it myself.

Heck, that’s where I started in my programming life – before auto formatters – so it comes naturally anyway, and for me it’s a way to pause and think about what I’ve written as I almost absent-mindedly clean up the indentation.

The future normal?

Former Member mentioned (on Slack) the other day something along the lines of “I’ve got my editor just how I want it now”, which implied to me a lot of care, attention and obsessive tweaking that I admire, but am thinking is – in some scenarios – less worthwhile these days. In my mental move to become a cloud native (see what I did there?) I’m moving away from becoming attached one specific editor and preparing myself for a future normal, which might be described nicely in a Colossal Cave style thus:

YOU ARE IN A MAZE OF TWISTY LITTLE EDITORS, ALL DIFFERENT

I’ve seen the platforms for writing and deploying code almost explode with possibilities and variations over the past decade, and it seems only to be going to continue. As we mentally and physically (well, logically) move away from our local workstations to the cloud, we cede control of our local tools. Perhaps one day the facilities in the cloud, naturally different because they’re provided on different platforms by different vendors, might coalesce via some sort of common standard, but I’m not holding my breath. Instead, I’m embracing difference, and continuing to manually obsess over whitespace in all the code I write, wherever it is.

How about you?

 

This post was brought to you by La Secreta coffee and the quiet of an early Monday morning.

 

Read more posts in this series here: Monday morning thoughts.

 

Update 02 May 2018:

The final results of the poll came in:

  • Total number of votes: 137
  • Those caring about whitespace: 87%
  • Those not caring about whitespace: 13%
To report this post you need to login first.

12 Comments

You must be Logged on to comment or reply to a post.

  1. Former Member

    Despite my previous comment I am inclined to agree with you DJ.

    I do have my workflow and editor tweaked to within an inch of what is perfect for me, and that is great when I have full control over my ways of working, there are however always external factors when working in consultancy.

    For example all of my formatting and linting options are tied to my code install on a usb stick and a client doesnt allow me to use USB, this means I am now code reviewing, code that is formatted as another development team saw fit. I have tried not to build an over reliance on my setup however I feel I am noticeably slower when having to work in a slightly different way.

    I think eventually our workflows will soon have to become platform and developer agnostic as much as our coding languages have.

    Also “VS-Code (which I also enjoy using).” – DJ likes microsoft product shocker….

    (3) 
    1. Dominique Pierre

      Hi,

      “I think eventually our workflows will soon have to become platform and developer agnostic as much as our coding languages have.”

      You can use a pre-commit hook to run the linter before committing your code.

      Cheers,

      Pierre

      (1) 
  2. DJ Adams Post author

    Hey Sean, thanks for the comment. You’re right – sometimes the environment simply isn’t under our own control.

    Your last statement (not the one about MS :-)) really resonates, so much so that it’s worth repeating here:

    “our workflows will soon have to become platform and developer agnostic”

    That’s very true. Cloud computing has been likened to utility computing, and on balance, I think that’s a good thing, regardless of this “price” we as developers feel we might be paying.

    (0) 
  3. Tiago Almeida

    Hey Dj!

    interesting post. I see this from two angles, the pragmatic and the hopeful.

    Pragmatic: we can’t expect our setup to work everywhere so we need to be prepared to work without all the autopilots we may have on a perfected setup (auto completion, auto formatting, etc.). That’s the same as a chef refusing to cook when he doesn’t have his knives.

    However, I do think these “editors” (cough textareas) you mention on these platforms are way too primitive. Competition between all these providers will eventually go into developer experience and they’ll have to look into this properly. Also don’t think building an IDE inside the browser is the way to go because it becomes yet another complex tool to learn to master and constantly changing tools makes developers slower (i.e. projects more expensive).

    There’s no reason why code can’t be developed locally and pushed to the cloud (via git or not) or maybe mounted over the web and just seamlessly edited. Hopeful this is where platforms like these will go.

    🙂

    (1) 
    1. DJ Adams Post author

      Hey Tiago! Great to hear from you, and you make some really interesting comments, so thank you.

      On the editors (or “textareas” – that’s a valid criticism, if a little harsh) – are they basic? Yes. Primitive? Well, I guess that depends on their purpose, but on the whole they’re no worse than, say, the editor built into Github. Now I’m not saying that’s the gold standard, but if it allows me to write short pieces of code and indent them correctly, and get the code to where it needs to be, let’s say, then I’m not too unhappy.

      But you are of course absolutely spot on when it comes to where code can be written. I too write locally; well, local for me is a cloud-based virtual private server, or Google Cloud Shell, but that’s the same as local – ie it’s a *nix environment with the usual tools. And I can commit to a git repository local to that and then push to a remote that’s acting as origin and / or the source for a deployment.

      So – definitely, git activities can be the glue that ties environments and workspaces together. For me, the “minimum viable product” here is a set of tools that work well together, and where none of them are on my own workstation. That doesn’t imply that I need or want a web-based editor (although I do like the SAP Web IDE very much, and have enjoyed using Cloud9 in the past too) but am ready to accept a temporary “dip” in tooling, in the context of the explosive growth of facilities and approaches that are cloud ready (such as FaaS).

      (1) 
    1. DJ Adams Post author

      Nitpicking is not a bad thing! 🙂

      You’re absolutely right, the original “Yet Another” comes from yacc. That said, my background finds me considering YAPC (“Yet Another Perl Conference”) more prominent as it’s a conference series I used to attend, and even (somewhere) have the tshirt, as the saying goes.

      But as the YAPC entry in Wikipedia says, the YAPC name is indeed in homage to “YACC”.

      Nicely done!

      (1) 
  4. Helmut Tammen

    Nice article, DJ although I’m wondering what you think about on monday mornings 😉

    I’m also using a lot of different “editor environments” and would love to work completely in the cloud cause everything is there as you left it the last time at another device. But I have to admit that I still sometimes (gets less as cloud editors get better) move back to my local editor, edit my code there and copy-paste it back into the cloud editor.

    As more and more editors support .editorconfig files it doesn’t really matter which editor you use. Maybe in near future the browser will pass our personal .editorconfig file to each cloud editor automatically and we can work with tab or space indention as configured?

    Although I personally need indentation and some basic formatting (Man is a creature of habits) I think there are other features that are more important, e.g. code completion. Nothing is more disruptive than moving to the other tab with the API documentation to look for the correct syntax and parameters for a function. Cause cloud computing get’s more usable from day to day my hope is that this will be injected into the different editors by the browser in the future. This would kill all the arguments of “hardware native developers”.

    Am I a dreamer? Maybe but in times where in first offline stores robots or virtual holo-shop-assistants help us with our decisions this should be possible, shouldn’t it?

    I should not forget to mention that my personal favorite editor VS Code already moved to the cloud. https://codesandbox.io/ uses it and MS also offers it on it’s cloud platform (in beta I think).

    (2) 
    1. DJ Adams Post author

      Thanks for your thoughts as always, Helmut. You’re right, the EditorConfig project is indeed a really nice idea, I just haven’t seen it as widespread as I’d like – and also I’m guessing if there’s a feature backlog for an online editor, adding support for .editorconfig files might be in there, but priority-wise I’m sure there will be other items further up the list. So it’s a constant struggle.

      Interesting that you mention code completion as an important feature. Personally I’ve hardly used code completion, even in editors that supported it. I like to write everything out “longhand” as it helps me learn, and get under the skin of the language or framework I’m using. I can better “taste” what I’m doing if it’s me that’s doing the typing, rather than a plugin. But I totally get how others really like such features.

      When you mentioned “there are other features more important” I thought you were taking a different tack, i.e. I thought you were going to say that features related to creating code, rather than directly involved in assisting in that creation, were important. So I’ll say it instead … At least with the contexts that I’ve experienced so far, code is certainly still key, but what we write must work in conjunction with other first class citizens in the solution, including source code control, configuration, event definitions, deployments, and so on. And features that blend assistance for those items are almost as important as features that help you write and format code. In my humble opinion only, of course!

      You’re not a dreamer – I think we all should allow ourselves to want to strive towards a better place, and by doing that we indirectly give that better place a bigger chance of becoming a reality.

      (0) 
  5. Frank Koehntopp

    Ooooh… EditorConfig sounds like a neat idea.

    Let’s take it all the way and reference from your oAuth login. Cloud Personalization at its best.

    We should pitch this to the WebIDE folks while we’re at it.

     

     

    (0) 
  6. Christian Schuff

    Hi DJ,

    nice blog post. Here are my five cents on code style:

    ESLint is totally capable of checking your code style. With a proper ESLint config

    eslint --fix

    will do a great job in auto-formatting your code while being totally editor-independent.

    The airbnb config is a great starting point btw: https://www.npmjs.com/package/eslint-config-airbnb

    I use .editorconfig in addition.

    BR

    Chris

    (1) 
    1. DJ Adams Post author

      Cheers Chris. Yes, I’m a fan of ESLint, but have only managed to use it either (a) where my editing workflow has been local to my workstation or (b) when it’s part of the bigger picture in the cloud (as it is, for example, in the SAP Web IDE. It’s great for gently enforcing coding standards too in a CI scenario.

      I guess what I’m thinking right now is that there are some editing scenarios where a facility like ESLint is not yet available or viable. But perhaps, as with editorconfig, that will come …

      (1) 

Leave a Reply