My first resume-worthy project was working with Mozilla on the Rust compiler for 6 months [0], implementing the ability to reorder fields in structs to eliminate padding. My work here was primarily a cleanup project which also unblocked many other Rust layout features that people benefit from today. I then detoured into Python/Django on top of Kubernetes, writing scalable infrastructure such as a giant media transcoding cluster. After that, I pivoted back to C/C++ working at Backtrace I/O. If you play a lot of videogames, our software is probably on your system, as we indexed and processed native crashes for many of the largest videogame publishers. This was big data on the order of tens to hundreds of terabytes per day. I was able to attain exposure to the concerns at that scale--including custom database design. While there, I spearheaded the adoption of Rust in the org, initially for microservices and later as part of our C codebase. I'm now one of the most experienced Rust engineers you'll find. We did neat things some of which are open source, for example our feature flag system that rewrote code at runtime [1] and our Sqlite VFS that replicates to S3 [2]. As a benchmark of our success, we managed to be acquired by Sauce Labs, a company easily 10 times our size.
Though we weren't successful in the long term, I also bring some business experience to the table as some friends and I did manage to run a contracting company for a while.
Outside of work I play around with DSP and audio synthesis projects, including optimization using lower level details such as SIMD. I also think about programming language design. Recently, I've been working to mod Factorio to make it playable by the blind. I am 100% blind myself, and I've managed to win it multiple times. You can get info on it at [3], and I did a stream which also demonstrates my ability to speak ad-hoc without much preparation at [4]. It also answers the question "how do you use the computer?", one of the more common questions I get. In terms of technical skill, when I joined the project it was one 20000 line file, and now it's maintainable and nicely split up.
My salary expectation is $200k+. I'm looking for mid-sized to small startups. At this point, I'm able to take some risks. Hopefully this interests you. I know I've said a lot. That's because I'm looking for the right fit, not the fast fit. If you hire me, I want to be there for the long term.
My first resume-worthy project was working with Mozilla on the Rust compiler for 6 months [0], implementing the ability to reorder fields in structs to eliminate padding. My work here was primarily a cleanup project which also unblocked many other Rust layout features that people benefit from today. I then detoured into Python/Django on top of Kubernetes, writing scalable infrastructure such as a giant media transcoding cluster. After that, I pivoted back to C/C++ working at Backtrace I/O. If you play a lot of videogames, our software is probably on your system, as we indexed and processed native crashes for many of the largest videogame publishers. This was big data on the order of tens to hundreds of terabytes per day. I was able to attain exposure to the concerns at that scale--including custom database design. While there, I spearheaded the adoption of Rust in the org, initially for microservices and later as part of our C codebase. I'm now one of the most experienced Rust engineers you'll find. We did neat things some of which are open source, for example our feature flag system that rewrote code at runtime [1] and our Sqlite VFS that replicates to S3 [2]. As a benchmark of our success, we managed to be acquired by Sauce Labs, a company easily 10 times our size.
Though we weren't successful in the long term, I also bring some business experience to the table as some friends and I did manage to run a contracting company for a while.
Outside of work I play around with DSP and audio synthesis projects, including optimization using lower level details such as SIMD. I also think about programming language design. Recently, I've been working to mod Factorio to make it playable by the blind. I am 100% blind myself, and I've managed to win it multiple times. You can get info on it at [3], and I did a stream which also demonstrates my ability to speak ad-hoc without much preparation at [4]. It also answers the question "how do you use the computer?", one of the more common questions I get. In terms of technical skill, when I joined the project it was one 20000 line file, and now it's maintainable and nicely split up.
My salary expectation is $200k+. I'm looking for mid-sized to small startups. At this point, I'm able to take some risks, including possibly volatile salary (e.g. crypto, bonuses, etc). Hopefully this interests you. I know I've said a lot. That's because I'm looking for the right fit, not the fast fit.
Strict or no, Google actually fails at accessibility a lot. The basically broken unergonomic keybindings in docs for starters and the entire fiasco that is Android come to mind immediately. For a really "fun" fail that's recent, Youtube recommendations are now a live region. This means that if you leave that tab focused, your screen reader just starts reading things while you're trying to play music and are across the room and can't stop it. That seems like a minor example except the whole point of Youtube is hearing things so that's kind of a big ball for someone to drop, thinking that live regions are a good plan. Things have improved some (I no longer hate the GCP console) but my point is that strict about accessibility doesn't mean good at accessibility by any means, and Google has a deservedly bad reputation in blindness circles that they earned over a very long time.
Sadly the screen readers do actually do a not-so-good job of this, but I think that may in practice be more a function of poor UI for switching indicators on and off. You get 80 cells at most, and even the most conservatively unambiguous abbreviations for controls are going to use 2-3 letters of that. Hit a line with a few links and half your display is gone. I'm not enough of a braille user to know how to go about fixing this for sure, but there is definitely an inefficiency. Ending up in a "but my favorite text-based browser is more efficient" position because it turns a bunch of this off, or because it's configurable in a way your favorite screen reader isn't, or etc is something I can see happening, but nonetheless the real issue there is that screen readers need to be fixed, not that we should go ask all the sighted people to support Lynx.
NVDA's flow for deciding which formatting you care about is to tab through a list of 30 checkboxes. They have hotkeys when the dialog is open but it's still less than ideal if, as I suspect, braille users need to change them more often. And there is also a potential education problem around teaching braille users that the way they get more efficiency is to change them around all the time.
My solution in the world of infinite resources would be to make the cells 5 or 6 dots high so that you can put the formatting in line with the characters it's for. That's something I thought would be useful for a long time. But sadly we live in the world where good braille displays will forever be expensive and thus doubling the price isn't doable.
I own a braille display and use the 93-volume trigonometry textbook from high school and the logic around it with respect to making sure the right chapter was in the classroom with me as an analogy when explaining CPU caches to people. In the long run I discovered that incredibly fast speech rates scale better than braille for most tasks outside educational settings, but if it works for you, by all means use it. And before someone inevitably makes the "but braille is important for literacy and brain development" point: it is, and I advocate learning it.
However, putting the burden on site developers to support text-based browsers for this use case is O(sites) but putting it on the screen reader developers is O(1). In other words only the latter scales. Braille isn't a very good argument for site authors supporting text-based browsers from any practical perspective, and in all honesty I think most of them would find this off-putting. It's already hard enough to get people to do accessibility; if we make the bar as high as that and go around claiming that it's necessary for accessibility, no one will ever bother.
I am blind. I know or have known at least 20 other blind people sufficiently to know what their browsers are. None of them used Links. One of them used Edbrowse. The rest (including myself) are Firefox, Chrome, or Safari. I have at least one personal project (not public) which uses React heavily. Saying that Links is necessary is an outdated view, so much so that we have things like the accessibility object model [0] in progress to possibly go so far as even supporting use cases like remote desktop connections in the browser by making fake screen reader only nodes in the accessibility tree.
In general, the terminal itself is even not so great. There are efforts like Emacspeak which mandate learning what is essentially a second desktop environment, but outside that it turns out that offering semantics (which only non-text browsers and apps can do) is useful: for example knowing whether or not the cursor is in a text editor, so that deletions are significant, or whether text is a table.
The idea that JS is bad for screen readers--or indeed that we use text-based browsers--is a consistent misconception that is no longer true. It was true 10 or 15 years ago, if not longer, but everything AT has come a very long way since then.
> The idea that JS is bad for screen readers--or indeed that we use text-based browsers--is a consistent misconception that is no longer true.
To be perfectly blunt, I feel this misconception is pushed mainly by people with an "anti-javascript" agenda.
If one can no longer argue that "supporting non-javascript clients is the only way to support accessibility", one is only left with "if you break support for non-javascript clients, you will only be excluding people who deliberately disable javascript". And at that point, the amount of effort to support non-javascript vs. the return on investment shifts heavily in favor of not caring about users who intentionally disable javascript. This is an argument I've had in every shop I've worked at and at the end of the day in every instance we decided it was simply not worth the hassle to support people who intentionally disable javascript.
In fact, I'm pretty sure any competitive search engine these has to have a very complex crawler that is more than able to deal with javascript rendered pages. If they didn't, they'd be leaving a ton of content out of their indexes--not a good look for a search engine. So not even the "you have to support text-only browsers to please google" argument has most likely fallen out of favor.
I see this like supporting DOS in 2019 or somesuch. There might be an esoteric reason to do so but when 99% of the userbase has left and the old thing can't support new technologies, saying that we need to support the old thing forever because a tiny subset of users still use it stops meaningful progress. If there weren't plenty of good, modern options I would be all for Links but there are, so I'm not. At some point it's on the user for choosing not to leave their little island of familiarity, especially when the user is technical enough to be using Links.
Firefox and Chrome both have mature accessibility API implementations at this point. Edge is also at least okay. Internet Explorer has worked forever. You then couple those with a screen reader--most commonly Jaws or NVDA--and you get something that very much resembles Emacs or what have you: there's around 50 or 60 keystrokes I use on a regular basis. It's like a local client-server model (indeed documentation on this topic uses those terms). You couple something implementing the server with a client, i.e. a screen reader, a one-switch controller, speech recognition, what have you, and those consume exposed semantic information. Browsers then map web pages to the platform's accessibility model for consumption.
NVDA offers scriptability for the web and otherwise in Python as well, so anything it can't do can probably be added. For instance there's an add-on for using your local screen reader to control a remote machine, provided that both run it (not the most applicable to accessibility, but a good example of how far you can take NVDA's scripting). Jaws also does much of this but is much more proprietary including an only half documented scripting language.
iOS is also good. unfortunately Apple very much dropped the ball on OS X and hasn't picked it up again, but my brother (also blind, it's genetic) did an entire business degree on an iPhone because he didn't want to be bothered learning a laptop. That's a loss in efficiency, but even the lesser options are now sufficient enough that a non-programmer can pick them up and go get a college degree.
There is an idea that goes something like "Obviously screen readers have to struggle to present information, therefore dedicated text-based browsers are better". That was true in 1995 when we didn't even have MSAA. I know people from that era and they had to hook APIs in other processes at runtime. But in actuality, once you expose the accessibility tree and hand it over to the people who want to use it, good things happen.
Ah, I'm sorry, I misunderstood what you meant. You're talking about screen reader compatibility only.
I was interested in hearing about browsers that do what Lynx does, but are better. Unfortunately, the browsers you mention are graphical, and so are not Lynx replacements.
From my perspective there is very little difference. The interface I get out of Firefox is exposed as if it were a text-based browser for lack of a better analogy (it's not quite the same, but the differences are subtle and not obvious at first glance). But I also get the ability to do all the non-text-based-browser things with that interface instead of being limited to what a text-based browser supports, and those things can be made accessible to me. But the really big advantage is that my skills at driving Firefox also work with Chrome, IE, and Edge, and any web view on the platform. Plus there is a large common subset that is shared with all the desktop apps as well.
I'm not the right person if you're looking for someone who shares enthusiasm for text-based browsers, in other words. In general I would like it if people would stop using blindness as a point in their arguments that they're necessary because it shows a massive misunderstanding of what the world of accessibility is like.
> In fact, I'm pretty sure any competitive search engine these has to have a very complex crawler that is more than able to deal with javascript rendered pages.
Save the region-specific engines which likely lag behind, Google [0] and Bing [1] both support crawling javascript, and Bing is generally the search engine index of choice for all other search engines like Yahoo, DDG (at least for now, I occasionally get crawls from duckduckgobot), etc.
I admit I have an anti-javascript agenda since most JavaScript on the web is used against me, to track me, show ads, autoplay videos, popups, exploits etc. I don't trust you, I don't want you to run code on my computer.
You're already visiting web pages that are directing your computer to access servers somewhat arbitrarily. You're running quite a bit of other people's code on your computer.
I appreciate your assistance but I can check spelling; a simple "Did you know that it's Lynx" would have sufficed. Good to know there's two text-based browsers. I didn't, but I and everyone else I know will go on not using either.
There's also a difference between those who acquire perceptive limitations (sight, hearing, also motor control, etc.) later in life, whether through accident, injury, illness, or degeneration, and those who have limitations from birth or a young age. Having to learn some (admittedly arcane) interface such as emacs late in life, with fewer capabilities and often declining cognitive capabilities, is difficult.
And yes, mainstream commercial software and OS offerings are improving. Slighty. (Most are still abysmally poor.)
I'm hard-pressed, though, to see how an increased dependence on dynamic and programmatic web design elements improves accessibility. Especially when wielded by technologists, managers, and clients with little awareness or concern for such access.
Again: Google should be much better positioned to grasp this than most. They clearly don't.
Google themselves are your example. Leaving aside some horrible accessibility keybindings in Docs, both Docs and Sheets are basically fully accessible. in fact Sheets is the best spreadsheet program I've used. It's not as powerful as Excel, but Excel is laggy for a variety of technical reasons that shouldn't exist, at least with NVDA. I can also read presentations in slides, and I might be able to make one. I've never tried; web or not, making slides just isn't something super feasible for a blind person if it's going to look any good.
I have gripes about Aria. It's definitely possible to abuse this stuff and end up with an inaccessible mess, but overall we have been trending toward a more accessible internet and things like the aforementioned do exist.
I've been blind since birth. I started on a device called the Braille 'N Speak 2000, which functioned very much like Emacs. I don't use Emacs because Emacspeak requires Linux desktop and adds a ton of extra complexity on top for very little gain. Linux dropped the ball big time on accessibility and audio in general, and never really recovered. Obviously this is opinionated, but I feel like you're implying that I lost my vision later in life and am forming my opinion around that perspective. You might additionally want to look into Jaws and NVDA. Learning those is about as bad as learning Emacs or etc; knowledge from when you were sighted doesn't transfer in the slightest and the interface is much more arcane than you probably imagine it to be.
> Docs and Sheets are basically fully accessible. in fact Sheets is the best spreadsheet program I've used.
This is off topic, and I don't want to distract from the current conversation, but speaking of sheets -- as a web developer, I often build SVG charts with d3, and I've been racking my brain lately trying to figure out how to make them more accessible to blind users beyond just linking to tables of data.
If you're using Sheets, are you also regularly consuming charts as well? Is there a common auditory shorthand for representing something like a pie chart?
Sadly no. Making charts accessible is an unsolved problem. There have been some efforts for accessible graphing calculators that work more or less, but it's not trivial to make a generic one-size-fits-all solution.
For Sheets, the underlying stuff that runs it is quite complicated. They ended up doing something akin to an offscreen model with HTML to make it work because afaik they use a canvas of some sort to draw everything. In fact, unless you turn on braille mode, both products actually have a built-in screen reader that talks via aria live regions. That's terrible practice, but to their credit they got ahead of what the internet was providing for accessibility and didn't have a choice in that regard.
For something you can practically implement without a huge project, I suggest text descriptions of the data. If you want to do a bit better, make it an HTML table--that'll give some convenient navigability for free.
In the insert case call the function InsertWithAllocqation, and also provide an Insert variant that doesn't allocate but can fail. In the reversing case, call the function ReverseInPlace, then require the user to make a copy either before or after. This gets you the same goal--not hiding the costly allocation--while also making it convenient to use and removing the possibility of mistakes.
The real problem is that without generics, such functions actually have to be written in the same fashion as sorting where you provide a function for reading and writing both, as opposed to just working--so the "simple" loops which are indeed error prone actually become less code, and we all use them instead. I highly, highly doubt even the best Google programmer will always get the boundary condition on that reverse a list loop right especially in an emergency or at 3 AM, and this is a very simple case where Go just can't abstract on par with anything-with-generics.
But my point is that you can meet the goal of not hiding operations just with good naming, if that's what you consider a terminal value of good pl design, and don't need to forego abstraction to do it.
I'm the blind dev who refactored a huge chunk of the Rust compiler [0]. I'm at roughly 800 words a minute with a synth, with the proven ability to top out at 1219. 800 or so is the norm among programmers. In order to get it we normally end up using older synths which sound way less natural because modern synthesis techniques can't go that fast. There's a trade-off between natural sounding and 500+ words a minute, and the market now strongly prefers the former because hardware can now support i.e. concatenative synthesis.
1219 is a record as far as I know. We measured it explicitly by getting the screen reader to read a passage and dividing. I spent months working up from 800 to do it and lost the skill once I stopped (there was a marked level of decreased comprehension post 1000, but I was able to program there; still, in the end, not worth it). When I try to described the required mental state it comes out very much like I'm on drugs. Most of us who reach 800 or so stay there, though not always that fast for i.e. pleasure reading (I do novels at about 400). it's built up slowly over time, either more or less explicitly. I did it because I was in high school doing muds and got tired of not being able to keep up; it took about 6-8 months of committing to turn the synth faster once a week no matter what, keeping it there and dealing with a day or two of mild headaches. Note that for most blind people these days, total synthesis time per day is around 10+ hours; this stuff replaces the pencil, the novel, etc. Others just seem to naturally do it. You have little choice, it's effectively a 1 dimensional interface, so from time to time you find a reason to bump the knob. And that's enough.
Whether and how much the skill transfers to normal human speech, or even between synths, is person-specific. I can't do Youtube at much beyond 2x. Others can. It's definitely a learned skill.
And as a followup to that--because really this is the weird part--some circles of blind people (including mine) talk faster between ourselves. That's not common, but it happens. I still sometimes have to remember that other people can't digest technical content at the rate I say it and remember to slow down. A good way to bring it out is to have me try to explain a technical concept that I understand really well. I have the common problem in that situation of not being able to talk as fast as I think, but I also seem to have the ability to assemble words faster in a sort of tokenize/send to vocal cords sense once I know what I want to say.
To me, the fact that this does in fact seem to be bidirectional at least some is more interesting than that I can listen fast.
I kind of want to hear a "blind Danish" conversation now. For those unaware: Danish is phonetically one of the most difficult languages in the world, to the point where children who acquire Danish as their first language on average start speaking a few months later than children with any other first language. To clarify: speaking is not the same as understanding - toddlers are often capable of understanding language before they have the motor control required to speak it, which is why baby sign language exists.
Oh wow, did not know that! Then perhaps a better way to phrase it is that it does not imply slower general mental development of the children - at least that is what I read elsewhere.
Are you Danish? (your account name looks rather Dutch)
I always wanted to know whether it's true what I heard some years ago: a friend told me that older Danish people are complaining that the younger Danish are harder to understand because there has been a trend in recent decades to swallow consonants even more than in the past
(that's something hard to image for me as a non-Danish speaker :)
No, I'm Dutch like you guessed. While the Netherlands and Denmark are very similar in some aspects (flat countries obsessed with having the best bike infrastructure in the world) the language is quite different ;)
Living in Malmö I also find this quite hard to believe! Besides, isn't old people complaining about the younger generation butchering their language something that happens all the time in all cultures?
This is vague, because it was long ago, but I remember reading an article in a newspaper (Dagens Nyheter, Sweden, IIRC) in... Oh, the 1990s, I think.
It was about how Danish linguists were worried about how the language was getting more unintelligible. The example I remember was about the ever-increasing number of words that are pronounced, basically, “lää'e”: läkare, läge, läger, lager... Those are written in Swedish here; some Dane may translate. (In English: healer, situation, camp [laager], layer...) There were more that I don't remember; in all, I think they mentioned at least half a dozen words that had become basically indistinguishable from each other.
I don't think serious linguists have had the same fear about most other languages.
It is common for any "in-group" to speak faster than the same people in other groups. This is commonly studied in linguistic 101 courses by undergrads because it is so easy to observe - in your own groups - once you are looking for it.
But when the in-group is defined as "is blind"?? I'm not just talking about programmers in this context, or any other cross-section wherein there's some sort of shared vocabulary and context other than the disability itself. I don't think it's been studied, but I've noticed, my parents have noticed, in general enough people around me have noticed it over the years that I'm convinced the effect is real. Is whatever mechanism you're referring to typically general enough that the group can be defined this broadly and still have it happen?
I don’t think this is a blind person thing. Ask any nerd about something they’re into, and you stand a pretty good chance of receiving a firehouse of words representing their steam of consciousness.
Has anyone tried overlapping words instead of speeding them up? Like so:
How
are
you
doing?
I often wondered if this, or at least sped up speech, should be the default robotic interface... it would make sense to optimize for efficiency/speed (while maintaining legibility) if we can do so.
Other people in realtime aren't...I guess the best way I have to put it is informationally sparse. There's a lot going on beside what's being said in conversation. Synths don't imply things for example; in a context with active implication slowing/pausing the synth is sometimes necessary. The skill doesn't extend beyond the blatant transfer of information. In social contexts and especially when you can't go off any visual cues whatsoever to figure out what the other person is thinking/feeling, there's a lot more going on than simple information transfer.
However most blind people I know who do this start hating audiobooks, start hating talks, and generally by far prefer the text option. audiobooks aren't annoying, but they're below my baud if you will. Net result: boredom/falling asleep to whatever it is and the need to actively make an effort to listen. Some things which require active listener participation--math lectures for example--are different. I guess the best way I can put it is that speed is inversely proportional to the amount of, I guess let's call it active listening, required.
I've given a lot of thought to this stuff, but we don't really have the right words for me to communicate it properly. A neuroscientist or linguist might, but I'm not either of those.
This is fascinating; thank you. How does an audio book read by the author, such as Anthony Bourdain's Kitchen Confidential, which contains autobiographical information, compare? Is it more like a social situation that you need real time to absorb, or do you prefer it at a higher speed? How does a stage play compare? Do you watch movies sped up?
Also, how does your "baud" vary with your familiarity with the ideas? I can't imagine it's independent. As a ~35 year old programmer with a decade of professional experience and a decade of hobby experience before that, I cracked open SICP for the first time and found almost everything familiar. I had digested the ideas from other sources, so I could read at a "natural" rate. If I had read it as a teenager, it would have been a mindfuck, and I would have taken multiple slow readings to understand. When you talk about numbers like 800, are you talking about writing that challenges you and changes the way you think, or are you talking about stuff you do for a living that is just information you're already primed to accommodate?
I haven't specifically tried different types of audiobooks to see if there's some preferred category.
With movies I don't bother with them unless they have descriptive audio, at which point you've got music, sound effects, and two somewhat parallel speech streams going on. That's high informational content.
I did an entire CS degree at 800 words a minute. I program in any programming language you care to name (including the initial learning) at that speed as well. For more complicated concepts I stay at that speed, but pause after every paragraph or so to chunk the content as needed. I'm doing this thread at that speed. Pretty much the only time I slow it down is pleasure reading or sometimes articles when i want to go off and do chores while I listen, but even then it's still faster than human speech.
In general i think answering these sorts of questions needs research that we don't have to my knowledge. Nothing in my personal experience or background really allows me to give you good definitive answers. The sample size to work with is pretty small and in all honesty there's not a lot of good research around blindness day-to-day in the first place.
> audiobooks aren't annoying, but they're below my baud if you will. Net result: boredom/falling asleep to whatever it is and the need to actively make an effort to listen. Some things which require active listener participation--math lectures for example--are different.
That sounds like a similar description to what it's like for people with IQs significantly higher than the average.
You can pass Espeak recordings around legally. It's just GPL. The license applies to the software, not the content produced via it.
I will attempt to remember and find the time to take my demo recording of this on Rust compiler source code that's currently in dropbox and put it up somewhere more permanent. I doubt Dropbox will care for me much if I allow HN-volume traffic to hit my account. It's Espeak using an NVDA fork with an additional voice that some of us like, so vanilla espeak is in the ballpark.
What I don't remember is if vanilla non-libsonic espeak softcaps the speech rate. It might. I believe new versions of espeak integrate libsonic directly, but that old versions just silently bump the speaking rate down if it's over the max. I haven't used command line espeak directly for anything in a very long time.
Libsonic is an optimized library specifically for the use case of screen readers that need to push synths further: https://github.com/waywardgeek/sonic
There is a range slider that maxes as 450, which is the maximum speed according to the manual.
I tried listening to a Wikipedia article at 450, I am so amazed you can comprehend that. Perhaps that's equivalent of me visually scanning the text instead of reading, however when I do that, I tend to focus on interesting parts for long stretches of time. With espeak, how do you focus? Can you pause it at will?
Screen readers have a lot of commands for reading different sized chunks of content. In general there's probably around 50 keystrokes I use on a daily basis. It's not as straightforward as reading from top to bottom, though it can be. I can usually do a Wikipedia article without pausing at 450 or so.
As an interesting sidenote, screen readers have to co-opt capslock as a modifier key, then there's fun with finding keyboards that are happy to let you hold capslock+ctrl+shift+whatever.
> Whether and how much the skill transfers to normal human speech, or even between synths, is person-specific. I can't do Youtube at much beyond 2x. Others can. It's definitely a learned skill.
I find that the maximum understandable rate varies a lot between speakers. For some speakers 2.5x is possible, but just 1.5x for others.
One advantage synths has, is that they can more easily control the speed at which words are spoken, and the pauses between words independently. When watching/listening pre-recorded content I often find that I'd want to speed up the pauses more than the words (because speeding up everything until the pauses are sufficiently short make the words intelligible).
If someone knows of a program or algorithm that can play back audio/video using different rates for speech and silence, please share.
Are old speech synths not harsh on the ears to listen for longer periods? Or maybe I'm just familiar with the super robotic ones (I like them for music production).
If so, have you considered using an EQ plugin to maybe turn down the harsher high frequencies a few notches? Just a thought.
They're harsh. But you get used to it in about a week. Espeak is an atypically bad example, which is why NVDA experimented with a fork (and maybe one day the NVDA work will make it upstream). part of what allows them to stay intelligible is the harshness. I've never tried passing one through an EQ but there are already pitch settings and similar to play with, and given that even not wearing headphones slows me down I expect that an EQ would probably be bad for it.
But more to the point there is nowhere to really plug that in to a screen reader, so we can't try it anyway. The audio subsystems of most screen readers are much less advanced than you'd think.
Programming languages: Python, Rust, C++, some JavaScript and Go
Technologies: Most of Google Cloud platform, Kubernetes, SQL (Postgres, BigQuery), RabbitMQ, PgBouncer, the Django/Celery stack, enough bash to be dangerous, CMake, Appveyor and Travis CI, some Windows COM.
I'm an experienced backend software engineer/generalist with experience on every level of the stack. Highlights include designing custom priority queues, writing a microservice monitoring solution, debugging distributed locks, and participating in multiple AWS to Google Cloud migrations. I've been involved with 4 billing systems and wrote two of them. My favorite professional project so far is an incredibly massive Kubernetes-powered media transcoding cluster. I've also got some extensive ops experience.
My experience with lower levels of the stack comes from my personal projects. The most impactful of these was implementing a significant optimization in the Rust compiler which reorders struct and enum fields to reduce the memory footprint of your code. It's much more complicated than it sounds. I've got a write-up on my blog [0] My other sizeable personal project is Libaudioverse [1] a large C++ library for audio synthesis not dissimilar to WebAudio [2]. Highlights include a parallelizing workflow engine and hand-written SIMD optimizations.
I'm looking for a full-time position with either scheduling flexibility or at least part time remote. My favorite technology is Rust, but I'm open to anything.
2: When I started, WebAudio was barely on the horizon. Once the spec reached a degree of maturity, I read it and realized I'd built roughly the same thing.
Programming languages: Python, Rust, C++, some JavaScript and Go
Technologies: Most of Google Cloud platform, Kubernetes, SQL (Postgres, BigQuery), RabbitMQ, PgBouncer, the Django/Celery stack, enough bash to be dangerous, CMake, Appveyor and Travis CI, some Windows COM.
I'm an experienced backend software engineer/generalist with experience on every level of the stack. Highlights include designing custom priority queues, writing a microservice monitoring solution, debugging distributed locks, and participating in multiple AWS to Google Cloud migrations. I've been involved with 4 billing systems and wrote two of them. My favorite professional project so far is an incredibly massive Kubernetes-powered media transcoding cluster. I've also got some extensive ops experience.
My experience with lower levels of the stack comes from my personal projects. The most impactful of these was implementing a significant optimization in the Rust compiler which reorders struct and enum fields to reduce the memory footprint of your code. It's much more complicated than it sounds. I've got a write-up on my blog [0] My other sizeable personal project is Libaudioverse [1] a large C++ library for audio synthesis not dissimilar to WebAudio [2]. Highlights include a parallelizing workflow engine and hand-written SIMD optimizations.
I'm looking for a full-time position with either scheduling flexibility or at least part time remote. My favorite technology is Rust, but I'm open to anything.
2: When I started, WebAudio was barely on the horizon. Once the spec reached a degree of maturity, I read it and realized I'd built roughly the same thing.
Remote: Yes
Willing to relocate: No
Technologies: Rust, C/C++, Python, SQL, Kubernetes, many others
Résumé/CV: https://ahicks.io/files/resume.pdf
Email: ahicks@ahicks.io
My first resume-worthy project was working with Mozilla on the Rust compiler for 6 months [0], implementing the ability to reorder fields in structs to eliminate padding. My work here was primarily a cleanup project which also unblocked many other Rust layout features that people benefit from today. I then detoured into Python/Django on top of Kubernetes, writing scalable infrastructure such as a giant media transcoding cluster. After that, I pivoted back to C/C++ working at Backtrace I/O. If you play a lot of videogames, our software is probably on your system, as we indexed and processed native crashes for many of the largest videogame publishers. This was big data on the order of tens to hundreds of terabytes per day. I was able to attain exposure to the concerns at that scale--including custom database design. While there, I spearheaded the adoption of Rust in the org, initially for microservices and later as part of our C codebase. I'm now one of the most experienced Rust engineers you'll find. We did neat things some of which are open source, for example our feature flag system that rewrote code at runtime [1] and our Sqlite VFS that replicates to S3 [2]. As a benchmark of our success, we managed to be acquired by Sauce Labs, a company easily 10 times our size.
Though we weren't successful in the long term, I also bring some business experience to the table as some friends and I did manage to run a contracting company for a while.
Outside of work I play around with DSP and audio synthesis projects, including optimization using lower level details such as SIMD. I also think about programming language design. Recently, I've been working to mod Factorio to make it playable by the blind. I am 100% blind myself, and I've managed to win it multiple times. You can get info on it at [3], and I did a stream which also demonstrates my ability to speak ad-hoc without much preparation at [4]. It also answers the question "how do you use the computer?", one of the more common questions I get. In terms of technical skill, when I joined the project it was one 20000 line file, and now it's maintainable and nicely split up.
My salary expectation is $200k+. I'm looking for mid-sized to small startups. At this point, I'm able to take some risks. Hopefully this interests you. I know I've said a lot. That's because I'm looking for the right fit, not the fast fit. If you hire me, I want to be there for the long term.
0: https://ahicks.io/posts/April%202017/rust-struct-field-reord...
1: https://engineering.backtrace.io/2021-12-19-bounded-dynamici...
2: https://engineering.backtrace.io/2021-12-02-verneuil-s3-back...
3: https://github.com/factorio-access/FactorioAccess
4: https://www.youtube.com/watch?v=QW2-ujG9PSE