I wonder if this explains why people forced to work in open plan offfices become less sociable? It’s well documented how illnesses travel in open plans.
All sorts. It could be a Python file with a dictionary of datetimes to targets for that week, it could be a file containing an enum of our suppliers, or (less a data file) it could be a template for a page on the site.
The point is that they are code, or a file directly loaded in, stored in source control, rather than dynamic data stored in a database that needs an editing interface.
It seems like that would be a ticket to a QA automation job, not a dev job. People say QA -> dev is a good way to get in, but I've seen very few people actually accomplish it.
I've seen it happen several times (my employer may be unusually prone to hiring jr devs as qa automation).
I agree that if you can hold out for a dev job, do that and save a year or two getting to the same place. If you really can't get a dev job and need the income, get a QA Automation job and start migrating early by asking to fix small bugs yourself, or work on the automation tooling.
At a smaller company, working on the build system and QA automation tooling might be more interesting and get more attention than what you would do as a jr software dev.
It was used only in the form of Emacs Lisp, as a set of tools for customer service folks to make replying to typical email easier for them. They pretty much built all that themselves (and they didn't start out as programmers).
We worked together with Eric Benson and Dan Bornstein on ScriptX [2], which was basically Lisp with objects instead of parenthesis.
I found ScriptX quite useful for web programming [3]: "Link Globally, Interact Locally"!
ScriptX's legacy lives on: After Kaleida shut down, John Wainwright, the architect of ScriptX, created a very similar language called MaxScript [4] for 3D Studio Max, which I later used at Maxis for programming the character animation content pipeline for The Sims [5].
There was more Lisp influence than just the CS macros you mention here. Eric Benson was a major contributor to Lucid Emacs and many early Amazon engineers had Lisp experience. SICP was practically issued to every new software engineer--it was that popular.
The template language for Amazon's website at the time (catsubst) was a Lisp-inspired prefix notation language with a relatively small number of functions. For example, there was an add macro but not a subtract macro, so to do A-B, you had to say ${add A -B}. I might have the exact syntax wrong since it's been 20 years.
EB and I both worked at Lucid, which produced a Common Lisp system, not to my knowledge a version of Emacs (though maybe so after I left in 1989?). Some other early employees knew and liked Lisp, but we didn't use it on any core functionality. The text substitution logic you mention, that I wrote, was really simple and not particularly Lisp-like. Though again, after I handed it off, who knows what happened.
Lucid Emacs -> Xemacs was mentioned in a sibling comment, but I remember people being in awe about EB working on those. There were many interesting employees back then--J. Chenault, J. Gehlen, R. Braumeller, F. Eiden, K. Sears, etc. I've lost touch with most of them but I learned a lot from them.
I started in October 1997 and did Perl work on backend systems, but I had a few friends who worked on the frontend. They used to talk about how Catsubst had a very small set of verbs and that everything was a function, even arithmetic, and that prefix notation was used for all macro calls. They thought it was Lisp-inspired, but they were also pretty junior programmers too. I never worked with Catsubst myself, so my information is second-hand, while yours is zero-hand since you wrote it. :-)
Thanks for all the work you did on Amazon's infra!
Yes, there was a ton of Perl in the early days. This came about because Paul Davis was a Perl aficionado and did a lot of script writing with it early on, and the non-programmers, of which there were n-2, could pick it up much more easily than C (of course). Which is how some of them became programmers. Incidentally, we used C, not C++, though I liked OOP, because I had previously had less than great experience using C++ on large projects. We used a C++ compiler though because it could catch more errors than the C compiler could. This is one area where Steve Yegge was a bit off in that famous post.
After leaving Lucid I was really not paying much attention to what they were doing. It wasn't long before things started going badly there and they were out of business a few years later. But indeed, I had forgotten what little of the Emacs history I might have known. Here it is: https://www.jwz.org/doc/lemacs.html
> I would be impressed with a tool to quickly design a web application in the same way Visual Basic did 25 years ago instead of talking about Bootstrap, Foundation, AngularJS, React, etc.
It's called ASP.NET Web Forms. Version 1 was released in 2002. Demos of it back then were quite impressive.
I tried it circa 2007 with Sharepoint and it was a pain in the * to use the web components/AJAX. It was the first time I used Sharepoint for development so take it with a grain of salt.
To this day I run a Windows 7 VM in Parallels on my MacBook Air in Coherence mode just so I can write blog posts in Windows Live Writer. I looked for years for a setup that could beat this, and unbelievably, never found it.
Not necessarily better, but sort of equivalent: Windows Terminal Server since version 2008-or-so has had "RemoteApp" support, meaning that you can configure the (multiplatform) Microsoft Remote Desktop client to connect to a (single running app on a) Terminal Services server with a similar UX to Parallels' Coherence mode.
Azure offers what's effectively "Running-individual-apps-as-a-Service" by booting TS server VMs and serving RemoteApp sessions from them. They have a demo to see how it feels (https://www.remoteapp.windowsazure.com/en/tour.aspx). If you don't like Azure, you could do something equivalent using e.g. AWS WorkSpaces instances.
Or, disregarding the networking aspect, you could just run your Windows VM headless on your MBA (and therefore using any VM software you like, e.g. VirtualBox) and RDP into it with the same RemoteApp configuration. It may or may not be more responsive than Coherence, but I'd bet on it being less battery-intensive.
Do you have any instructions on how to do RemoteApp with AWS Workspaces? I use an AWS Workspaces box to run a few key apps on Windows, and I'd love to use them in a more Coherence-mode style.
Checking further, it looks like AWS WorkSpaces doesn't actually support any protocol other than "Teradici PC-over-IP"—I'm guessing that whether or not you enable RDP on the remote, the AWS firewall policy won't expose the port. (This is apparently on purpose; WorkSpaces advertises "keeping your data on-premise by never exporting it to the client; the client only gets pixels.")
I guess plain EC2 Windows instances will still work, though. The setup is simple enough:
1. on the instance, select a base image of any edition of Windows 7/8/10 that supports receiving Remote Desktop Connections;
2. enable receiving Remote Desktop Connections on the instance's System prefs (might already be enabled if that's how they expect people to connect to manage their instances);
4. use the tool to generate an RDP connection profile on the instance—naming the session and browsing for an EXE path is usually enough;
5. in the same tool, generate an .rdp file for that session, and get it back to your computer;
6. import the .rdp file into Microsoft Remote Desktop;
7. edit the new RDP connection to supply the correct server address (from the client's perspective) and prepopulated authentication credentials.
Now launching that RDP session should give you e.g. a Notepad window on your desktop.
Note one restriction: if the EC2 instance you're running isn't a Server edition of Windows, you'll be restricted to one RDP session at a time. There are things you can do to get around this, though I'm not sure they're compliant with the Windows EULA.
---
† The actual, official thing you're supposed to do is to have a Server-edition instance running the "Remote Desktop Connection Broker" service; the Server Manager app, pointed at that machine, then lets you manage "RemoteApp and Desktop Connection Resources" (i.e. an RDP session directory).
Interestingly, the "session host" instances that the Connection Broker, well, brokers for, can be any edition of Windows (but are usually Enterprise); productivity apps aren't written for, or tested with, Server-edition Windows, after all, so it wouldn't make sense for the instance the users actually connect to to be a Server.
The tool above basically skips the Broker by giving you the same .rdp profile the Broker would answer with after you negotiate with it. This is why the process feels so manual: if you had a Connection Broker server in-between, it'd be the thing transparently plugging in all those details for you, basically taking the .rdp "template" you get from the tool and filling out the client-side creds from the client step of the negotiation, and the server-side address by picking one of its load-balanced pool members.
I use MarsEdit on a Mac and (mostly) like it. I used Live Writer way back when but, at some point, I stopped doing so--don't remember why but I'm pretty sure it was before I switched off Windows.
MarsEdit is the client most people mention as a Mac replacement for Windows Live Writer, but after using WLW for years and then trying MarsEdit, it didn't hold a candle to WLW. It's shocking--WLW is a free tool that hasn't had active development since 2012--but true.
The reason is probably that the market for blog editors disappeared when WYSIWYG editors became good enough for most people and wifi became common. The level of hassle "fat clients" in the space end up being (with crappy caches, blocking interfaces etc) is not offset by the tangible benefits of offline editing and marginally-better media support.
I'm not a great fan of the Blogger editor, but I've not found any modern alternative that can beat it so much to consider paying for it.
The Blogger editor was so bad, for writing a blog with any amount of code snippets, that I got frustrated enough to bail on Blogger entirely and write a simple hand-rolled blog engine. There was absolutely no way to get it to not mangle the resulting content - even directly editing the HTML wasn't really reliable.
> It's hard for a lot of people on here to imagine dealing with 100k+ other coworkers but at a point you oftentimes have to abstract away what makes people human to work in most large corporations.
Working myself for a company of 150K+ employees, I can confirm this is totally true.
I hate a lot of high-level business speak like "resources", but what I've come to realize is that one cannot think of 150K people as individuals. It's too much for the human mind. If you see this as an indictment of large corporations, I wouldn't blame you. Just realize it's a reality of operating inside them.
Our CI server monitor has 3 modes: Red, Green, and Tiger Cage Released.
Future iterations will involve individual angry badgers in climbing harnesses located above each developer's desk. `git blame' will identify the build-breaking commit and react accordingly.
