retroflexzy

A significant part of my job, unfortunately, is helping people fix their workspaces when Perforce (p4) goes bad, or creating guardrails and wrappers to stop Perforce doing bad things.

In fairness, p4 predates most of the VCSes we consider "modern", so I empathize with a lot of the underlying architecture decisions. However, it has and continues to utterly fail at improving at a reasonable pace.

For example:

  - p4 tracks file metadata of client workspaces on the server (sync'ed locally, opened for edit, file revision, etc) and uses this as the basis to avoid doing unneeded work.  If this becomes desync'ed, a reconcile or force sync must be used.  A reconcile can take hours, potentially days; it tries do detect file moves by default, so likely at least O(c^n) for some c>1. I have never personally seen a default reconcile operation _complete_ over any modestly large game code base, and in practice, people accumulate a litany of workarounds and scripts to fix this for themselves.

  - Scripting p4 is a nightmare. Documentation is poor, schemas do not exist, and all the language-specific libraries are just thin wrappers over its C++ API.

  - By default, p4 "helps" you with text files by "correcting" line endings on sync or even converting between encodings. This works until you have a mixed-OS environment, and discover a part of the pipechain that _must_ have a certain style.  There are various levers to pull to make this better, but I've yet to find something fool proof.

  - By default, p4 keeps flies read-only, only unlocking them when explicitly marked as being edited.  This means, to avoid having to do this manually, every tool you use needs to be p4-aware.  Or, you can turn this off, and choose to contend reconcile instead. (See above)

  - Branching a modest game project, with, say, Unreal source code, can take hours.  And this is the quick version where you ask the server to simply create new metadata, with no file transfer to a client.

  - p4 is licensed by the user-account. Every user entity in p4 not intended exclusively for performing backups and maintenance operations counts toward this, including users required to integrate with other services.  Plus, often times, these integration users must have admin access to be useful. The security posture is horrific.

A writing system that used strict phonetic transcription for everything would be unusably bad.

This is, for better or worse, what is being done to incorporate aboriginal names into things like streets and bridges in places like Vancouver.

- [stal̕əw̓asəm Bridge](https://en.wikipedia.org/wiki/Stal%CC%95%C9%99w%CC%93as%C9%9...) - [šxʷməθkʷəy̓əmasəm Street](https://vancouver.ca/news-calendar/musqueamview-street-signs...)

I see the practicalities of adopting this IPA-lite form, but it's a struggle to use, even though I've previously been trained in IPA.

Back in my youth, after the Internet became common but before Wikipedia, I tried to discover the answer to this and came away disappointed again and again. Every article I could find simply stated "because light scattering", and barely much more.

How does scattering work? Why does light scatter? _What does scattering even mean in the context of light?_

After C:, it really is just allocated in order.

Between CD/DVD drives, writers, Zip Drives, and extra hard drives, it wasn't unusual for a workstation to naturally end up with G: or H:, before mapped network storage became common.

Ansible is a complete mess. You're better off managing things with Puppet or Salt, as that gives you an actual declarative mechanism

We thought this, too, when choosing Salt over Ansible, but that was a complete disaster.

Ansible is definitely designed to operate at a lower abstraction level, but modules that behave like desired state declarations actually work very well. And creating your own modules turned out to be at least an order of magnitude easier than in Salt.

We do use Ansible to manage containers via podman-systemd, but slightly hampered by Ubuntu not shipping with podman 5. It's... fine?

Our mixed Windows, Linux VM and Linux bare metal deployment scenario is likely fairly niche, but Ansible is really the only tenable solution.

It was "fun" discovering this the hard way a number of years ago when active US Android user count for a game we were supporting dropped 15% essentially overnight. The TCP stack in the client only did IPv4.

The challenge, ironically, was convincing management that adding IPv6 was the thing worth trying. After almost a week of getting nowhere (and almost 2 weeks of outage), I forced the issue by saying "Look, I'm doing this. I need one engineer for 2 days. If it doesn't work, then it doesn't work."

He got the change implemented in 2 hours. QA OKed it the next day. The topic never came up again.

I once attempted to use XSLT to transform SOAP requests generated by our system so the providers' implementation would accept them. This included having to sufficiently grok XSD, WSDL el at to figure out what part of the chain is broken.

At the end of the (very long) process, I just hard-coded the reference request XML given by the particularly problematic endpoints, put some regex replacements behind it, and called it a day.

Or, at least, not giving a fair take on its particular approach to open source.

We both self-host and pay for the service. There is ample engagement from the development team with the larger community. There are also a myriad of open source projects without the same licence restrictions that Sentry-the-company publishes or maintains which make up key functionalities in Sentry-the-product.

There was a period in World Rally Championship history when the top drivers would manipulate the starting order for the following day's stages by intentionally slowing down before the end of the stage. It was bizarre to watch teams intentionally give up 10+ second margins when stage wins can come down to half-second gaps.

Neat! Takes me back to highschool... https://lostmediawiki.com/Minesweeper_Flags_(lost_Windows_Li...

There is a cursor rendering fix in xf86-video-radeonhd (or perhaps -radeon) that flips a single bit.

It took the group several years to narrow in on.

uv implements PEP 723.

https://packaging.python.org/en/latest/specifications/inline...

Especially useful if the script has dependencies on packages in private repos.

Here is a list of all rotations systems known to be in use by various Tetris implementations: http://harddrop.com/wiki/Category:Rotation_Systems

(I'm assuming you are a Canadian student due to referring to the work as "Co-op")

In general, Canadian labour laws prohibit what are typically considered unpaid internships, although it varies slightly by province.[1][2] My understanding is that this is not the case across most of the United States.

[1] http://www.labour.gov.on.ca/english/es/pubs/internships.php [2]: https://www.labour.gov.bc.ca/esb/igm/esa-part-1/igm-esa-s1-w...

A nice segue into a key point about Linguistics, and some Japanese facts.

The study of Linguistics, explicitly, does not deal with orthography, or the written system of languages. There are of course exceptions with good reasons, but orthography systems are rarely, if ever, good representations of the systems of auditory communication that are formally considered languages. An orthography system can be heavily influenced by geopolitics (Chinese), have severe ambiguities (Arabic, the various Latin alphabet systems), or have been created retroactively (many languages of indigenous peoples). While it is convenient to map a spoken language to its related orthography when discussing topics such as syllables, inflection, and morphology, it is rarely appropriate when studying linguistics formally.

As for Japanese, while it is true that its alphabet system has a relatively straightforward mapping to its phonology, the mapping itself is, unfortunately, not unambiguous. Japanese has a tonal system[1] that is not explicit in its orthography. There are examples of phonemically distinct words that are identical when written in hiragana/katakana.

Finally, there exists a moraic system[2] which sits between the phonemic and syllabic abstractions. Japanese, especially, have many phenomenons that cannot be adequately modelled unless working in this in-between system.

[1] http://en.wikipedia.org/wiki/Japanese_pitch_accent

[2] http://en.wikipedia.org/wiki/Mora_%28linguistics%29

An Aeron of the wrong size will definitely kill circulation in your thighs. The difference is surprisingly obvious once you try the various sizes.

Yes. I can't really talk about it, but, yes.

To English speakers, using different counters for different classes of nouns is a pretty strange feature...

Strange, perhaps, but present. To a native Chinese and Japanese speaker like myself, the list of collective nouns for animals in English is staggering, almost mindblowing, and appears absolutely arbitrary: http://en.wikipedia.org/wiki/List_of_collective_nouns_by_sub...

I'm surprised no one has brought up how difficult it often is to incorporate design changes into an existing project unless it has been developed with such accommodations from day 1. Even a seemingly simple software project can be monstrously complex under the hood, and something as innocent as "this button should be larger than the rest" can mean weeks and months of proofing, coding, and testing. (e.g. Firefox 3's back button)

Whether a change comes in the form of code fixes, documentation improvement, refactoring, design changes, or infrastructural modifications, the burden of understanding the potential scope of damage and doing the actual work is always, always on the contributor. Convincing another to take on the work on their behalf is always a possibility, but it should not be hard to see why design changes proposed through such a channel will often be pushed to the back of the queue, unless for some dire need.

Designer or coder, there is no excuse for not doing due diligence in making sure a contribution is a good contribution.

Looking at the discussion so far, there appears to be at least some consensus that non-trivial effort above and beyond the (hopefully) expected hand-holding must be dedicated to designers in order for them to become good contributors. And, in corollary, the natural conclusion is that it's unrealistic to expect designers to put in the necessary effort to become good contributors on their own.

Following from the above, the more crucial questions, I think, are "How do we convince projects that they should go out of their way to attract designers", and, "Do you really need designers? Really, really, need them?"

That makes me sad because I've never made more than 1/3 of that as a developer in Vancouver.

What's more, the second source cited is basically a copy-n-paste of the Telegraph article.

Phoronix can pretend to be a reliable primary source all it wants, but it's questionable stuff like this that makes its reporting a complete joke amongst the X and DRI/Mesa development community.

> I'm inherently suspicious when someone says something like "conveys information", but then says "logic and reason" don't work.

Actually, the study of semantics, which is highly logical, will often fail at describing the "true meaning" of an utterance. This is where pragmatics come in, and, frankly, a far more interesting area of study and occasionally even applicable in every day life.

The most useful thing I got out of my semantics course was that I never, ever, want to take that stream ever again.

(Disclaimer: I've not studied any of these languages in detail; the following is a mix of what I have studied, personal knowledge, and logical conclusions derived from both)

Structurally, Japanese and Korean is almost identical. The morphology system are similar, they have the same word order, are both tonal in a similar way, and there are even parallels that can be drawn in terms of their phonology; some words are even phonemically identical. However, their core inventory of phonemes is quite different: there are sounds in Korean that just do not occur in Japanese. Like Japanese, the categorization of Korean is debated; Wikipedia is helpful here if you want to know more.

Now, Mandarin Chinese is entirely different. The tonal system is different, it lacks an overt inflection system, word order is different, and the phoneme inventory is, again, different. While there is vocabulary sharing going on, it's hard to see any technical relationships between them.

I've heard a number of different stories on how the Korean peninsula and Japanese archipelago were settled by the Chinese, from the Chinese, but it just doesn't seem plausible considering the linguistics of the regions. What history I did study in Japan simply never mentioned it. And, to be honest, that is the extent of my historical knowledge of the languages.

Right. I think I would file all of that under the "hard to translate" category.

Now, let me clarify upfront that my minor (technically a "joint-degree", but effectively a minor) is in Linguistics, so this may get wordy and technical.

What you are mostly describing is a not a restriction of the language itself, but of social conventions. You can certainly say "いいえ、できません". While it is true that Japanese has a relatively substantial honorific structure when compared to English, there are other languages with even richer systems, such as Malay.

One thing that makes Japanese stand out amongst the ones you have listed is the fact that it is a language isolate, meaning there are no other languages that are "linguistically related". (While technically in the Japonic family, there is some controversy around the categorization of Japanese dialects, which muddies the family categorization as well). Korean is another isolate, and, as far as I know, the only language that is remotely like Japanese in terms of grammar and morphology. German, Dutch and Spanish all belong in the Indo-European family, and there are some obvious structural similarities. Mandarin Chinese is certainly not Indo-European, but it also lacks a non-trivial inflection system, and has a basic word order that is not unlike Germanic languages.

Japanese, on the other hand, does not share this trait. Consequently, there are certain grammar constructs in English that are essentially impossible to transform into Japanese; it takes a speaker sufficient in both to first completely comprehend an utterance and then re-express it. Add to this the many subtle semantic differences in words, and it's not surprising that you will get a lot of "that's hard to say"s. However, this doesn't mean that something is untranslatable. Speaking from experience, us polyglots do occasionally use it as an excuse that more precisely means "the exchange which must take place for me to extract more context out of you to effectively perform your request is something I don't want to spend energy on at the moment." ;)

> Nowadays, there's some factual statements that are almost literally impossible to say in Japanese because the words/phrases/grammar to say them don't match up.

Care to elaborate? As a English/Mandarin/Japanese speaker, I am certainly acutely aware of the limitations of translating from one language in to another, but find such an assertion hard to accept without concrete examples.

I do something similar with my site, but without the extra intermediary repository. On a push, the server-side hook simply hard resets the content of the folder to the tip of a specific branch. The website itself acts as the canonical repository of, well, itself.

http://yangman.ca/blog/2009/08/06/website-management-with-gi...

Definitely some good advice here.

I never wanted to make this about myself, but I thought it appropriate to point out that I just received and accepted an offer from a place I interviewed with last week (one of the few fantastic interview experiences I've had). Much thanks to all the encouragements and good lucks, and even queries.

Now, please ignore this message, and return to our regularly scheduled discussion. :)

To be honest I just wanted to see if I could get a few good stories out of people on the other side. I expected some good advice to come out of this regardless, but certainly had no intention of making it about me.

The first point really shows an employer that actually cares. To be honest, out of all the places I have interviewed, there was only one instance of being questioned about the specifics of an open source project; it was for a QA position, and actually just a Pick-from-List kind of question. Oddly enough, not too many of them seem interested in actual code I can show them.

The second point, I think, deserves some more discussion.

There's no denying it: I consistently fail at coming up with questions to ask when an interview nears its end. Although I do try and ask small questions along the way, after the whole thing is done, there's just nothing else I care to know about that's appropriate at this stage in the process. In terms of work environment, if it was interesting enough to talk about, the interviewer would have already given me a spiel or the topic comes up naturally. The actual work gets discussed in some detail regardless, so there's not much else there without actually working on it. Having some opinions about the product in question would be nice, but no such luck there either: they've all been doesn't-exist-yet, enterprise apps, and generally things the general public doesn't have enough access to to be able to have an informed opinion about. That said, if the other side cooperates, I generally try and make the interview into more of a conversation, and seem to leave a very positive impression on the interviewer. Doesn't really help with the having-a-question-to-ask at the end, though.

What sort of questions do you really hope a keener would ask?

Ditto.

And the provider implementation is my own, running on a server I have physical access to, with a self-signed certificate.