We had a terrible release management system. (For IBM iSeries folks, it was Turnover.) And we used it for everything. Java code included. In particular, we used it for database migration scripts. And you know how database migration goes. You keep adding files and you never remove any. And there gets to be quite a few very quickly at the beginning of a project. And the folks in charge of setting up the release management system for our database migration scripts did so in such a way that we had to list out each one individually. Every release, we had to type like 50 database migration script filenames one-by-one. With no tab completion. (Not to mention the Java .war files we were deploying as well.) And by "release", I mean every release to the dev environment.
(Now some of you who know of Turnover might know of a janky Eclipse fork that would let you create Turnover forms in a drag-and-drop way rather than through the green screen, but there were reasons we didn't want to go that direction. Long story.)
As soon as I figured out how much of a PITA this would be every single day, I decided to do something about it. I wouldn't ask for permission. I'd ask for forgiveness (if it came to that.) So I set about writing a way to automate this. That way involved running the dumb terminal emulator (the "green screen" app tn5250j) in Xvfb and simulating key strokes to it. God was it a nasty hack, but it worked reliably and God was less painful to deal with than what we had before.
Part of why I didn't ask permission was because I wasn't entirely sure I could make it work and I didn't know if the boss would ok a project that may pay off given our tight deadlines. But once it did work, I didn't keep it a secret and the boss praised me for it. Still don't know he'd have let me undertake that project had I explained and asked permission ahead of time, but everything very much worked out with that project in the end.
Here's to lying to your boss. Don't ever feel bad for saving your boss from themself.
The article says early on that under California law, third parties intended to benefit from a contract can enforce those terms and that's "the crux" of Conservancy's lawyers' argument. But near the end it says that depending on the ruling in Conservancy v. Visio, we may get precedent that "anyone in the United States who wants GPL source code can sue for it, contributor or not." Any idea how it is that this case about California law could set precedent relevant to little old me who lives in Not-California, U.S.A.?
Of course it would be relevant to me because if someone sues some other hardware vendor for GPL'd source code and wins pointing at precedent set by Conservancy v. Visio, they'll likely publish that source online where I can get it, but that's not what I'm asking about.
Much ink has been spilled by many a philosopher on the topic of whether or not numbers "magically exist." Plato was the obvious example of a philosopher who believed numbers "exist" independent of our universe. Though no one is saying they exist "in the physical universe", but it's not a given that they cna't possibly exist if not "within our universe."
Think of it this way. Graham's number is an absolutely enormous number, right? Let's assume for the sake of argument that nobody has ever computed the Graham's-number-th digit of pi. We know for certain that there is a Graham's-number-th digit of pi. And we know that if two people calculated it independently, they'd get the same digit. But (at least in this hypothetical) nobody has actually ever done the calculation to see what the Graham's-number-th digit of pi is. Given all I've said so far, the act of finding out the Graham's-number-th digit of pi seems more like an act of discovery of something that already existed than an act of invention of something that didn't already exist. So, it seems quite reasonable to many to conclude that numbers "exist."
Also, Iah's view does imply that our universe does not encompass all of existence. It also implies that no calculation device need exist anywhere.
If Iah's view is correct, after the game, there will be at some versions of you who witnessed the Mets winning, some that witnessed the Yankees winning, and some that saw the game end in a tie. (As well as some for which the game was interrupted by aliens landing on the field and some where all the players spontaneously disappeared etc.)
So, subjectively, it'd still feel as if you'd gone to the game without knowing what was going to happen and then exactly one outcome (and not all outcomes) happened. But from a more objective perspective, all outcomes are indeed on an even footing.
- `go generate` for embedding resources into the executable. So intuitive and beautiful.
- Strict curating. It's the kind of language that things don't get into unless they're the right solution.
- Performance! Python was my favorite language before Go got sufficiently mature. It was refreshing to have that much efficiency coming from Python.
- `if err != nil {`, dammit!
- Imports referring to the location where the code can be got. `import "github.com/fogleman/gg"` for instance.
- `go fmt`. Nuff said.
- Tabs as the standard indentation character.
- `fallthrough`
- `init()`
Dislike:
- nil. I wish nil had a smller role in the language. It's an agreed best practice in Go that a zero value should be a ready to use thing. I feel like that would be easier to do (and more true of the core language) if the zero value of a slice/map was an empty slice/map, the zero value of a pointer was a pointer to a zero value of the type it points to, etc. Maybe this can't be done for all types (function and interface types, for instance), and maybe there are good reasons for the way it is that I'm not smart enough to realize, but if it could be done for some types, it would be nice.
Things I Pretty Much Eschew:
- Generics are limited. Maybe I'm missing something, but I doubt I'll be using generics as they are very extensively at all. If we could make generic types that would be something I could see myself using more.
We had a terrible release management system. (For IBM iSeries folks, it was Turnover.) And we used it for everything. Java code included. In particular, we used it for database migration scripts. And you know how database migration goes. You keep adding files and you never remove any. And there gets to be quite a few very quickly at the beginning of a project. And the folks in charge of setting up the release management system for our database migration scripts did so in such a way that we had to list out each one individually. Every release, we had to type like 50 database migration script filenames one-by-one. With no tab completion. (Not to mention the Java .war files we were deploying as well.) And by "release", I mean every release to the dev environment.
(Now some of you who know of Turnover might know of a janky Eclipse fork that would let you create Turnover forms in a drag-and-drop way rather than through the green screen, but there were reasons we didn't want to go that direction. Long story.)
As soon as I figured out how much of a PITA this would be every single day, I decided to do something about it. I wouldn't ask for permission. I'd ask for forgiveness (if it came to that.) So I set about writing a way to automate this. That way involved running the dumb terminal emulator (the "green screen" app tn5250j) in Xvfb and simulating key strokes to it. God was it a nasty hack, but it worked reliably and God was less painful to deal with than what we had before.
Part of why I didn't ask permission was because I wasn't entirely sure I could make it work and I didn't know if the boss would ok a project that may pay off given our tight deadlines. But once it did work, I didn't keep it a secret and the boss praised me for it. Still don't know he'd have let me undertake that project had I explained and asked permission ahead of time, but everything very much worked out with that project in the end.
Here's to lying to your boss. Don't ever feel bad for saving your boss from themself.