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.
Java was tacked on to AS400/iSeries so I can understand how it would be painful with any Change/Release management system. I would much prefer to stick with the old crufty RPG/CL on those systems. Tacking on "new" tech to old "green screen" systems is just a bandaid. Should have went to a modern OS at that point. Try doing JSON/CRUD apps on TSO/MVS. Not fun.
Instead of hiding the project until completion, you could (after a little covert research) share the idea with the boss and time box the development: if the first increment of X days or a week continues to look promising, then attempt the next increment as long as the boss still has an appetite for your idea.
I've not had to do this often or in awhile as over the past decade until very recently it's been a tech workers market and I've had more power, but I've spent (sometimes personal) time in past jobs to automate these kinds of things.
What I eventually learned to do in Kafkaesque organizations is do it anyways. If it works, ask for permission to spend time developing it, stressing how much time it'll free up. If it never gets approved or shot down, I use the solution anyways and use the time savings to focus on other things (which can vary on actual work which I present as spending "non-toil" time on, to taking mental health breaks).
At some level it's dishonest, but that's what happens when organizations stifle initiative.
Just because someone decided to be cheeky and call their license "unlicensed," doesn't mean I'm confused about what license are or aren't... If I wrote a license that granted no rights and decided to call it "Public Domain (TM)," would you also berate people who explained to other what actual "public domain" means?
I didn't berate you at all, my comment was pointing out the confusing naming of the unlicense. It was pretty obvious that I was being cheeky in my previous comment.
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.
Generics as currently implemented in go are so limited that you may as well stick with interfaces for anything but trivial boilerplate or textbook data structure/algorithm implementations.
For example, it's currently impossible to define type constraints with user-defined interfaces embedded:
```
// this is legal
type MyConstraint interface {
int64 | float
}
type SomeAPI interface {
AMethod() error
}
// Nope
type CantHaveThisConstraint interface {
int64 | float | SomeAPI
}
// NOPE
func SomeGeneric[T CantHaveThisConstraint](...) {
}
```
It's true that doesn't work because you can't mix types with methods and types with no methods. But that's a far cry from "Go doesn't have generic types" or "may as well stick with interfaces for anything but trivial boilerplate".
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.