WisCon Schedule + About Me

May. 23rd, 2016 02:35 pm
brainwane: My smiling face in front of a brick wall, May 2015. (Default)
[personal profile] brainwane
I'll be at WisCon this year, arriving Thursday the 26th and leaving incredibly early on Monday the 30th (to get to PyCon). I look basically like my profile photo, with slightly longer hair; you might recognize me as @brainwane from Twitter. My pronouns are she/her. I eat mostly vegetarian but will eat fish/poultry that has at least one hippie buzzword (e.g. "organic", "free-range", etc.).

I'm speaking in three sessions:

  1. Panelist on "The Fandom Awakens" (on Star Wars): Friday, May 27, 2:30-3:45 pm, Assembly.

  2. Comedy auctioneer for the charity auction benefiting the James Tiptree, Jr. Literary Award: Saturday, May 28, 7:30pm-probably 8:30pm or 9pm, Capitol/Wisconsin room.

  3. Panelist on "SIX SEASON SERIES BASED ON THE THREE-PART TRILOGY BASED ON THE SINGLE BOOK OF THE NOT ANOTHER F*CKING RACE PANEL" (comedy game show focusing on people of color): Sunday, May 29, 4:00-5:15pm, Wisconsin room.

Also, I will probably drop by the Clothing Swap portion of the Gathering on Friday afternoon to find pieces that suit me and to bask in other people wearing my donated stuff; I would like to drop in on the vid party on Saturday night; I would like to drop in on the Hamilton singalong; I have a Dessert Salon ticket and intend on attending the Guest of Honor and Tiptree Award speeches on Sunday evening.

I am easily lured into talking about Hamilton, Zen Cho, Star Trek, the Marvel Cinematic Universe, the Mahabharata, Hinduism, and other interests in my profile.

Please ask before hugging; sometimes I'd rather not.

I am often bad with names, and will remember 5 minutes into our conversation that we had an awesome deep conversation one year prior. I apologize in advance. Also, I will probably be a little less intensively social this year, because I am trying to actually sleep enough and thus get to PyCon reasonably well-rested, and because client work for my consulting business may come up; I'll probably be trying to sleep every night from about 11pm to 7am, and aiming to take some alone time on top of that. So if you and I have multiple chances to see each other in person at other times of year, I may choose to make time for other people instead; apologies.

The fact that I am, in a sense, succeeding Ellen Klages in serving as the Tiptree auctioneer is quite a responsibility and I hope to discharge it well. So if you came to the Tiptree auction and raucously laughed at my japes I would welcome your chortles.
[personal profile] mjg59
Github recently introduced the option to squash commits on merge, and even before then several projects requested that contributors squash their commits after review but before merge. This is a terrible idea that makes it more difficult for people to contribute to projects.

I'm spending today working on reworking some code to integrate with a new feature that was just integrated into Kubernetes. The PR in question was absolutely fine, but just before it was merged the entire commit history was squashed down to a single commit at the request of the reviewer. This single commit contains type declarations, the functionality itself, the integration of that functionality into the scheduler, the client code and a large pile of autogenerated code.

I've got some familiarity with Kubernetes, but even then this commit is difficult for me to read. It doesn't tell a story. I can't see its growth. Looking at a single hunk of this diff doesn't tell me whether it's infrastructural or part of the integration. Given time I can (and have) figured it out, but it's an unnecessary waste of effort that could have gone towards something else. For someone who's less used to working on large projects, it'd be even worse. I'm paid to deal with this. For someone who isn't, the probability that they'll give up and do something else entirely is even greater.

I don't want to pick on Kubernetes here - the fact that this Github feature exists makes it clear that a lot of people feel that this kind of merge is a good idea. And there are certainly cases where squashing commits makes sense. Commits that add broken code and which are immediately followed by a series of "Make this work" commits also impair readability and distract from the narrative that your RCS history should present, and Github present this feature as a way to get rid of them. But that ends up being a false dichotomy. A history that looks like "Commit", "Revert Commit", "Revert Revert Commit", "Fix broken revert", "Revert fix broken revert" is a bad history, as is a history that looks like "Add 20,000 line feature A", "Add 20,000 line feature B".

When you're crafting commits for merge, think about your commit history as a textbook. Start with the building blocks of your feature and make them one commit. Build your functionality on top of them in another. Tie that functionality into the core project and make another commit. Add client support. Add docs. Include your tests. Allow someone to follow the growth of your feature over time, with each commit being a chapter of that story. And never, ever, put autogenerated code in the same commit as an actual functional change.

People can't contribute to your project unless they can understand your code. Writing clear, well commented code is a big part of that. But so is showing the evolution of your features in an understandable way. Make sure your RCS history shows that, otherwise people will go and find another project that doesn't make them feel frustrated.

(Edit to add: Sarah Sharp wrote on the same topic a couple of years ago)
beable: (gonzo journalism)
[personal profile] beable
So My friend S and I had the following conversation by SMS at lunch

S: I just got catcalled? Praised?? LOL
S: On my bike, waiting for a turn signal, and I hear "hey girl", I turned my head before I heard the rest. Saw the person in the car pull up next to me with a big grin and thumbs up and realized the rest of it was "way to use your hand signal" hahaha

Me: Praised sounds like an oversell.
Me: Actually that sounds humourous enough to be less creepy.

S: Well apparently my hand signals are noteworthy.

Me: Hey girl, you breath oxygen like a pro.

S: Lmfao

Me: Hey girl, you're mitochondria is really working it
Me: Hey girl, entropy ain't got nothing on you!
Me: I think I should start marketing my mad skillz to pick up artists

S: I can tell this is gonna be a meme

Me: We need art! Get me the best photo shoppers in ALL the land!

S: So long as I can be in your marketing video. LOL
S: We could do it with the great masterpieces ... Birth of Venus

Me: Lol does the birth of Venus breathe?

S: Hmm, good point, I don't think so. I'll have to think on this project awhile.

Me: Hey Girl, you keep being your hydrated self and visiting that portapotty!
Me: #IKnowSexy

S: I'm gonna choke on my lunch.
S: Hey girl, you pressed that elevator button like a pro.
S: Hey sexy, I love how you showed up for work today.
S: Hey sugar, way to go dipping that fry in that ketchup

Me: I think we need to stick with Hey Girl
Me: It's classic for a reason

S: Hey girl, the way you flinch when I call you girl makes my heart soar
S: Hey girl, your ability to spot a classic meme is on fleek

Me: I am so not cool[1]

S: Hey girl keep being your awesome not-cool self

At this point we diverged a little into talking about where each of us was having lunch (not included because of identifying information), and in the course of that, S speculated that the reason the 3 guys one table over had so far managed to refrain from commenting on how awesome her mitochondria was because they were clearly members of the clergy.

Me: Girl, they don't know what they're missing.
Me: You gave the bestest mitochondria
Me: Have. Damn autocorrect.

S: I literally in the literalest sense am lmfao in this restaurant
S: Gave works even better it sounds naughty

Me: lol. We are so awesome we need to sell this awesome.
Me: T-shirts

S: Hey girl if only you were a boy

Me: Jewellery
Me: Thong underwear[2]
Me: Thong sandals

S: Stawp. Stawp or they're going to kick my ass out.

Me: I'm laughing so hard I can't breathe
Me: Postage Stamps?

S: Well you can trademark sayings and them sell all that stuff on redbubble
S: Maybe not postage stamps
S: But miniskirts yes

Me: Postage stamp sized skirts

S: I can add these sayings to the banana skirt!
S: Ok I'm stepping away from this phone now

Me: Ok seriously if I remove identifying info can I post this to my blog?

1: I'm not, because I blinked at the word fleek
2: This got lost in the visual transcript because scrolled to overzelously in my phone

Alternatively, our SMS Conversation in a series of screenshots )
[personal profile] mjg59
Moxie, the lead developer of the Signal secure communication application, recently blogged on the tradeoffs between providing a supportable federated service and providing a compelling application that gains significant adoption. There's a set of perfectly reasonable arguments around that that I don't want to rehash - regardless of feelings on the benefits of federation in general, there's certainly an increase in engineering cost in providing a stable intra-server protocol that still allows for addition of new features, and the person leading a project gets to make the decision about whether that's a valid tradeoff.

One voiced complaint about Signal on Android is the fact that it depends on the Google Play Services. These are a collection of proprietary functions for integrating with Google-provided services, and Signal depends on them to provide a good out of band notification protocol to allow Signal to be notified when new messages arrive, even if the phone is otherwise in a power saving state. At the time this decision was made, there were no terribly good alternatives for Android. Even now, nobody's really demonstrated a free implementation that supports several million clients and has no negative impact on battery life, so if your aim is to write a secure messaging client that will be adopted by as many people is possible, keeping this dependency is entirely rational.

On the other hand, there are users for whom the decision not to install a Google root of trust on their phone is also entirely rational. I have no especially good reason to believe that Google will ever want to do something inappropriate with my phone or data, but it's certainly possible that they'll be compelled to do so against their will. The set of people who will ever actually face this problem is probably small, but it's probably also the set of people who benefit most from Signal in the first place.

(Even ignoring the dependency on Play Services, people may not find the official client sufficient - it's very difficult to write a single piece of software that satisfies all users, whether that be down to accessibility requirements, OS support or whatever. Slack may be great, but there's still people who choose to use Hipchat)

This shouldn't be a problem. Signal is free software and anybody is free to modify it in any way they want to fit their needs, and as long as they don't break the protocol code in the process it'll carry on working with the existing Signal servers and allow communication with people who run the official client. Unfortunately, Moxie has indicated that he is not happy with forked versions of Signal using the official servers. Since Signal doesn't support federation, that means that users of forked versions will be unable to communicate with users of the official client.

This is awkward. Signal is deservedly popular. It provides strong security without being significantly more complicated than a traditional SMS client. In my social circle there's massively more users of Signal than any other security app. If I transition to a fork of Signal, I'm no longer able to securely communicate with them unless they also install the fork. If the aim is to make secure communication ubiquitous, that's kind of a problem.

Right now the choices I have for communicating with people I know are either convenient and secure but require non-free code (Signal), convenient and free but insecure (SMS) or secure and free but horribly inconvenient (gpg). Is there really no way for us to work as a community to develop something that's all three?
Page generated May. 26th, 2016 12:31 pm
Powered by Dreamwidth Studios