34 comments

[ 3.3 ms ] story [ 77.9 ms ] thread
This article got my attention.

Hats off to the author. Ok, I'll consider Azure for projects of any language. (Mission accomplished for the author.)

You should also consider getting consulting from his company BlueMetal who is a Microsoft partner :)
The same thing got around my head as well - I think I'm gonna try Azure soon for one of my little side-projects to see how it's gonna work out.
DevOps as in "Azure DevOps", the product formally known as TFS and/or VSTS, not the practices/culture surrounding the movement.

Basically, this walks through building a CI pipeline that builds C64 code. Which, don't get me wrong, is cool.

Not sure what I was expecting, I just really hate that Microsoft named their product this way, for exactly this reason.

Yeah the new name is really bad (as per usual with Microsoft). The previous one, Visual Studio Online bring no confusion and when very explicit about what it is. It's a bit saddening as the service is great.
Unless it's an online IDE, "Visual Studio Online" is probably just as bad a name.
The amazing thing about Microsoft is that once developers drink the kool-aid they will bend over backwards to evangelize whatever MS serves them. This is an example of that. Azure could not pay for better marketing.

Not sure I read this one correctly but I think he said he was opposed to VMs in the cloud. Lol.

Azure is a good product, though. And, more importantly, the person is familiar with it.

If I was doing something similar, I'd probably use GCP. Not necessarily because it's superior (i like it a lot, btw), but because I can achieve my goals faster that way.

There is something liberating about letting MS make most of the choices for you- never worrying about a new language or what is the best logging library, or how best to chain three logging libraries together or what not. You just deal with what MS has chosen, no matter how suboptimal, and start coding.

Of course MS has created its own dead ends, and has situations where the best solution is just a warmed-over c# version of what Java does. But, especially if the code is just a means to an end, sometimes it's just best to go hard with the tools you know.

It feels warm at first, then you feel colder...

We have to convert about a bazillion XAML build descriptions to the new format. Thanks MS. At least the 40 years old Unix stuff just keeps working if you don't have any particular reason to upgrade.

Off topic, but wasn't there a famous comment around the warm at first and then starts feeling cold..around peeing? Do you happen to know the exact comment?
I've heard many variations on the same theme, it's what I alluded to. Feels good at first but it's not a long term solution. :)
Because contrary to what UNIX devs think about development environments like Windows, we do like to be pampered instead of developing software like 40 years ago.

This also applies to Apple and Google's stacks.

Did you try the service before ranting? It have been available for years for free and keeps getting new features. I don't like the new UI, but as a private git repository it is solid. We also get recently a huge extension of free build time.

Which other services there are that provide that level of quality and ease of use for free without forcing you to open your source code?

but I think he said he was opposed to VMs in the cloud. Lol.

I am opposed to VMs in the cloud because if all you need is VMs there are much cheaper alternatives. Every seasoned cloud guy knows this! Generally in a “big 3” cloud I would use a VM only if a managed service didn’t cater to my use cases, and there are alot of managed services now...

(I make an exception for workloads that can tolerate preemptible VMs obv, that can be very cost effective )

It's not kool-aid, it's Microsoft's tradition of giving unusual names to existing things. I can easily imagine the same article about CircleCI or Travis, but it would be named "CI for Commodore 64" and therefore it would be less (accidentally) clickbaity.
> The downside of this decision would mean that I would sacrifice having syntax highlighting for 6510 assembly language, and I would be stuck starting at black text on a white background. Not exactly consistent with the “right tool” statement I just made.

Perhaps this is a "get off my lawn" moment for me, but really? You can't deal with a text editor sans syntax highlighting? For 6510 assembly language? It's nothing more than four columns of

    label opcode operand comment
    label opcode operand comment
Kids today (now I have to adjust the onion in my belt).
I have used syntax highlighting since Turbo Pascal 1.5 for Windows 3.x/Turbo Pascal 7.0 for MS-DOS.

So even around 30 years ago it was already a thing.

I think the point is that 6510 ASM is so simple one shouldn’t need syntax highlighting, because there’s almost no syntax.
Well, I still find it conformable to be able to quickly distinguish between comments, labels, mnemonics, macros, strings and numbers.

TASM with Turbo Vision based IDE, yay!

Back in the day this was ok. Look at actual stuff and you see that it is all cross development, macros etc. Visually structuring your code helps a lot focussing on the hard parts.

It is about getting all the need you can get, not settling for less. ;)

Indeed. I will be called lazy here but I just use the default vi or vim install on a Linux / Unix box usually and live with it. It turns to my advantage when I am suddenly on a box without all the usual desk toys available. Just sit down and do work. No adjusting the curtains first.

Plus things like vim autoindent just don’t work very well on yaml etc and get me annoyed.

This came from an event in about 1998 where I was stuck on an airgapped sunos box for 3 months.

So if you take a look at the screen grab of that -https://operation8bit.files.wordpress.com/2018/10/feature_sy... - you will notice that he’s highlighting an assortment of assembler directives with colors far away from the opcodes, and that there’s a jsr highlighted in red. Presumably jmp is also picked out: HEY THE PROGRAM FLOW CHANGES HERE. Feels pretty useful for skimming the code a few days later when you’ve forgotten the details. Or for commenting and cleaning up a disassembly of someone else’s code, I remember drawing lines on printouts to try and unwind what was happening...

Also of course if you are going to do something insane like build a completely automated workflow to go from “a file full of assembly” to “a browser window opens with an emulated c64 running your code” in one keystroke, you may as well fuck around with writing a syntax highlighter while you’re at it.

I don't think usefullness of syntax highlighting depends on complexity of syntax. It's useful not because it's hard to distinguish between e.g. builtin operator vs function call, but for some subconscious visual clues and making wall of text less uniform. For assembly it might be even more useful because otherwise code may look like solid column of text.

AFAIK, there's no theory why syntax highlighting is useful. There's movement against it, one of famous proponents against syntax highlighting is Rob Pike, with his Acme editor. However, most people still prefer having highlighting enabled.

The contrast on the text is waaaaaaaay too low, making it very hard to read :(
~60% black and a lightweight sans-serif font for body text ... none of these are bad on their own, but the contrast is a bit low when used all together
1) Open inspector 2) Go to <body> tag 3) Uncheck "font-weight: 300;"

But why I have to do this...

I just stopped trying to read it. If we all do this lower readership will make low contrast a top x thing to avoid.
Ok, I'm impressed. Very cool.
love this article. kind of cool and good proof of what you are trying to show in it.
The real challenge is whether the author can do DevOps with tools native to the C64.

What he has done is no different for those working 8bit microcontroller (Atmel AVRs, Intel 8051s and many others).