2,270 karma · joined May 22, 2009
You can find more info about me on my website https://davesnider.com
Can contact me dave.snider [at] gmail.com
Here's a screenshot http://snid.es/d156c6b7deea
In mine, under profiles/keys, I've set ⌘s to [17~
This is essentially F6, which I then bind in vim to
nnoremap <F6> :w<CR> imap <F6> <Esc>:w<CR>
I do this with a lot of ⌘ or otherwise unbindable settings (again, this only effects iterm2). This is how you can get iterm2 to pick up any keybinding and send it to vim as something else.
iTerm2 is amazing. I've been using it for years daily and it is 100% one of the best, most reliable pieces of software in my toolkit, right next to Alfred.
Show you love for George and contribute to his Patreon[0]. We always love to complain about how to make money with open source on HN. I'd love to see him making a lot more than he does, if for no other reason than we can get more people working full time on the project and provide some redundancy for a critical tool we all love. I wish I could pay for it, but I guess Patreon works.
All of our components are built for keyboard / screenreader support and accessibility was one of our primary goals since the beginning. We take it serious and it's baked into our review process. It's fairly mature and is now two and a half years old with a solid team working on it full time. At the very least you might find some ideas for your projects. It's also TypeScript-backed and themable through a Sass layer with native dark mode support.
We welcome contributions and if there's any students out there thinking about hacking on a component library for summer of code you can find some projects over here[3].
Other projects out there similar to ours that are pretty mature are Microsoft's Fabric[4] and Atalassian's Atlas Kit[5]. Both of which are open source as well. Generally we tend to have more features, and they might be a little easier to theme or modularize. Chakra UI[6] is a new comer that is smaller, but people seem to like as well. There are a lot of options these days and most of them are tailored towards a certain use case, since it's hard to target everything.
I research this stuff a lot so if anyone has any questions about component libs give a yell.
[1]: https://github.com/elastic/eui [2]: https://elastic.github.io/eui/#/ [3]: https://github.com/elastic/gsoc [4]: https://developer.microsoft.com/en-us/fabric#/ [5]: https://atlaskit.atlassian.com/ [6]: https://chakra-ui.com/
I remembered the person, but not anything about what I'd said that day. I assume it was just what I normally say. Having that last realization made me feel even better.
The easiest, most rewarding thing you can do daily in your life is appreciate the people around you. We all need that feedback.
The publishing industry is kind of terrible, and the line between real journalism and critique died somewhere around 2008. If I were to pick a point, I'd look to when Jeff was fired by CNET after he gave Kane and Lynch an unfavorable review. But you can see it in the degradation of every major gaming news outlet that used to have full-time employees with a platform stable enough to not bow down to PR teams.
That type of blowback would never happen today because any journalistic wall between the PR folks pushing these products and the content creators no longer exists. YouTube has successfully weaponized content. We like to talk a lot today about how great it is that we don't see ads. That's kind of lie. They are certainly there and we see them everyday, it's just now embedded in the content itself. The journos can't compete, because the PR firms block access to coverage unless the story is preconceived. As an example, back in the day we used to boycott Call of Duty "review" events where they'd fly you in a helicopter at a hotel so you could play the game for 6 hours with someone over your shoulder.
Fandom and "fun" content creation was always a loose proposition ("will i still be doing this at 40" was the bar night saying), but now it's just a quick hit slog. I sympathize with these folks to a degree. They're all independent, they all have no idea if this will be a job even next year, so of course they will take on any sort of shilling to keep their dream going. They need to hustle. It's like running a one-person startup.
I'm more worried about the 10s of thousands of other sad bedrooms where this is pushed as a real industry and a way of life. When startups fail, we engineers and designers fall back to jobs with the skills we learned. It's not as easy for people whose skill was trying to be funny on camera. There's a lot of people chasing the dream at the moment, and of course that's no different than trying to be a movie star, but part of me winces when I open up twitch and see that all this awkwardness is so public and often permanent.
If anyone is curious about where some of this could go, I'd recommend reading Super Sad True Love Story by Gary Shteyngart, a sort of near-future fiction that got a lot of this stuff right before it happened. I consider it the Network (as in the 70s movie) of our age. I fear for the day when the influencers and streamers make their way out of their bedrooms and into our public spaces, and we'll all be part of the show.
I love Fish. I'm likely not their target audience.
I've been using it for years. Since the early days in 1.x land for sure. The homepage has never changed and I still laugh at the tagline. I find it's auto-completion, history and niceties indispensable. I'm the person who asks you what the command is to rerun the tests. With Fish I never have to ask you again. I just remember part of it, and suddenly I've got it.
I find its scripting language much simpler to follow than bash. I don't have a lot of scripts, but the ones I do are easy to manage. The only hiccup I get into is when I have to look up something on stack exchange, and of course the example is in Bash. These days though, with Bass and fisherman and so many other tools, i have options.
Years ago I would explain to other code friendly designers, I'm weird, don't use this stuff. Go grab zsh. Lately though it's gotten very friendly. Really the only downside for a light scripter like myself is that need to convert bash examples to fish problem. Beyond that I feel it's actually a much nicer shell for new to terminal folks.
Anyways, just an anecdote to add to the pile. Thank you to the devs that have supported it over the years.
My story has very little connection with this one (which is quite thought provoking). It just had me thinking about how a simple recipe somewhat saved my own personal life (in a much more mundane way).
2 or so years ago I was tired of being a little overweight. I say this as someone who was an athlete for most of my life and in my 20s just developed the "usual I sit at a computer all day and drink beer at night" belly. I was self conscious and I just didn't feel great.
Anyways. I lost the weight. I didn't follow any fancy diets or doing anything complicated. I simply replaced my lunch with a fruit smoothie (usually just banana, milk and whatever berry I had) and then cut out drinking beer. Alcohol was still fine, but the single serving nature of beer vs. wine kept me from drinking a couple beers randomly. I drink a bottle of wine a week with my wife and enjoy it.
It very much became a routine, no different from my monthly vimrc cleanup. I didn't have to think about it, it just became part of who I was and took zero time. It helped that I'll admit I actually really enjoyed banana smoothies and wine. I could never do Soylent (I love my dinners!), but I understand people who entertain the idea of food as routine. Vacations I let myself go, which makes vacations even more exciting.
I don't think I'd have been able to keep to the routine without also working at a distributed company full-time. At previous jobs lunch was social, and after work drinks were social. I sometimes miss that stuff, but not really. My body feels better, which is great, but I know those hours just ended up back in my work (which to me was fine, I genuinely enjoy my work).
If you need that functionality these days Framer and it's bridge product is nearly magic. You can set up some basic shim wrappers on your React components and things work perfectly.
Before React came around I wrote and used some mootools/prototype/jQuery, but very frankly didn't really know JavaScript and just used them for tricks like carousels or basic AJAXy things. For example, in the Django or Smarty/PHP days (yes, like I said, a long time at this) I just had regular old CSS/HTML with a whole set of "filters" in whatever the templating system was. It was very, very easy to read the docs and do |dateformats or something for example. I could also |sort things really easy. It was just a filter. I didn't need to learn the actual python and it already did the hard work to make sure whatever I had WAS sortable.
When I started getting into React I was somewhat taken aback. I needed to actually learn Javascript (for real this time) to just do basic things. I also needed to understand very Reacty type things like how things mount. States were fun and easy to understand, except dealing with previous states. With states I could replace all that jquery which was mostly me just adding and removing classes onto things anyway. That side was much better, but it took me months to actually learn enough JS to actually understand how the "template" format of a React component was structured. Also, EVERYTHING needed to be imported. Want to do some basic color stuff? There's a library to import. Want a way to truncate things? Sure, again, let's import something that works for more than just simple string limits. Eventually you end up just writing a lot of JS that does this without some huge dependency, but that took awhile to learn as well. The biggest thing I missed was something like Django's template docs. All that stuff was just built in, and I didn't need to piece it together myself. Ultimately I think that's what makes it harder. The world of Javascript is fractured at its core. Want to learn how to write a function? Which version? Have fun doing a google search and getting something that is the "right" way to do things. OK. Now it's fat arrows...etc. JS just has years of old examples available.
Once I got past all this, it was obviously fantastic and feels like the right way to do things. It let me realize some personal dreams by really building a design system of shared components, not just a CSS library. Now I could take those design skills and build out stateless components that you could piece together like lego bricks. Engineers would then take that stuff and build to their hearts content and I didn't have to worry so much about them abusing a selector. I could even document things and show real variations with very simple prop changes. All of this sounds pretty rote and is of course what React is there for, but man did it require much, much more knowledge that what I was doing for "frontend design" back in the sever side rendering days. To this day I know what redux, context and hooks do, but have real difficulty dealing with them day to day. It's beyond the rendered DOM and so far away from what I'm looking to do as a designer who just wants to make things look good.
I continue to think coding is invaluable for web designers and to be honest is the only true way to hit zenith in your understanding of the medium, but I really don't envy people starting from scratch that have React as the "easy" way to do things if they are moving from just handing you a mock. I think it used to be much easier to get into "coding" as a designer 10 years ago. It's likely why I run into more and more designers that simply aren't interested in it or think it is impossible. They work in these React houses and suddenly have to learn a whole lot more just to do the basics.
I guess what I'm trying to say is. Hey, I work at a big company with a great team doing what most people would consider high-level React work that is used by at least hundreds of engineers. But most days if I'm honest I struggle with it too, and I've been at it now for 20 years. That's totally normal if you still call yourself a "frontend designer" rather than "frontend engineer". I know and work with the later all the time. They are fantastic people with a different skillset even though we work within the same files.
Anyways, if you're a designer who hit the wall with this stuff: keep at it. You'll get there. The great part about React is that you can start small. Start with the React Create App and just build a widget. Don't jump into Gatsby and suddenly have to worry about GraphQL, routing, image resizing and all that stuff. Just build what you built in HTML, but in React. Add some props as "variables" in your document. Move on from there. You'll get there.
I still have trouble with JavaScript and have to look up how to deal with arrays and objects all the time. Maybe in 20 more years that part of my brain will match what I can do on the CSS / design side. Until then, thanks to all he engineer folks who put up with me and take on the hard stuff.
Generally just using the system font is fine for most UI interfaces and the only good reasons to change it are:
1. You have a specific branding style you need to achieve (this is becoming rare) 2. Your interface has pixel perfect user created content where the difference in font to font usage between OSes / Browsers would cause actual breaks in layouts from user to user.
I run into the later often, and so we end up picking a neutral style font like this because it's the closest thing to a generic "system font" like Roboto or San Francisco that has a friendlier license.
Personally I prefer Inter UI https://rsms.me/inter/
I came from a really good high school that offered a breadth of knowledge across fields. When I went to college (granted in 1998) to become a "web designer" the curriculum and training was just not there. My first year was taking variations of the same math courses, the same english courses and a couple comp sci courses (teaching Java). It was heartbreaking. Anything design related involved drawing classes.
I dropped out mostly because I was too disheartened by what college was and didn't end up going to class. I was instead hacking in my dorm room on HTML, CSS and Photoshop. When I dropped out it led to immense guilt in relation to my family, who very lovingly had done everything they could to set me up to succeed. It was only a year later when I had a surprisingly decent pay check to show my parents that they didn't consider me unmotivated.
College isn't for everyone. It's especially not good if you know what you want to do and have mastered some manner of self-learning. For those of us that figure that stuff early, it's much better to just jump into the work and figure it out. In those ways I somewhat value a good high school as more important to college. It was there that I learned to learn and could explore my interests in a well-rounded curriculum.
I'm conflicted about how I'll deal with the scenario when my own kids grow up. I married a teacher, and speaking for myself I do very much value liberal arts educations. I just think a lot of those introductions need to be provided in High School, with secondary education focused more towards whatever your career is. If you don't know what that career is yet, I think potentially waiting a couple years to go to secondary education (be it college or trade school) till you know is a better bet.
My big takeaway is there isn't some magic formula for this. Everyone is different and we shouldn't pressure certain paths.
All that said, it certainly works fine as a general kit, and we build it with that practicality, it's just not something we officially support.
As far as stability, my team is pretty well resourced (and growing if there are any engineers interested!). We're using the library in many places around Elastic and its not going away anytime soon.
I've looked through most of the kits out there and they all have their pros and cons. Likely our biggest selling point is that it aims to be fully accessible and comes with a lot of fun charting libs. That puts its sweet spot for use in enterprise applications. It's also completely themable with about 8 lines of Sass variables.
Hey. I'm Dave and I'm looking for a front-end engineer with a designer's heart to come help me build out pattern libraries and component systems for use at Elastic (makers of Elasticsearch and Kibana). Specifically it would be working in a lot of React, Sass and SVGs. Your code would be fully open source. The design team here is small and this is a unique opportunity to build out design that is consumed by a large team of engineers. The company is fully distributed and has the usual bevy of great benefits. If you have great attention to detail and know the ins and outs of scaling a component library I'd love to talk with you.
If interested feel free to apply at
https://www.elastic.co/about/careers/engineering/jobs/825257
Engineers in general are more than welcome to peruse the other jobs at Elastic, of which there are quite a few.
Markdown doesn't have that problem because you can't do much with Markdown.
I prefer Markdown.
It's readable and easy to start writing by non-technical folk. More than that that, it's less flexible and isn't as likely to be destructive. At the end of the day rST is as complicated and as flexible as something like HTML. The biggest problem is its ability to nest markup. Markdown is pretty flat and you're not putting lists within tables within blockquotes. As someone making a theme, it was pretty difficult to style against the level of nesting that people end up using rST for. This is of course me bitching about how people write their rST, but there it is. I think rST by nature leads to inconsistent markup.
Basically what I'm saying is. At that point, I'd rather just write HTML. rST sits in some weird middle world where it can get very verbose, but you end up losing all the simplicity that you wanted in the first place.
Also want to note that rST doesn't HAVE to be so complicated. Plenty of people write clean, rST docs. However, as someone who spent a good deal of time learning the Sphinx system and the markup quirks of rST, in general I ended up seeing people use it in all sorts of crazy ways which then led to weird styling errors.
When it came time to document my own projects, I just built a simple markdown system with a tree structure and added some syntax highlighting. That's gonna get most projects 95% of the way there. While you can do a lot more with rST and it is really powerful, I really think it's only for those 5% of projects or more than likely, scientific documentation that needs more context.
http://blogs.msdn.com/b/oldnewthing/archive/2014/09/23/10559...
Remember reading this in The Right Stuff, and it was likely in the movie as well.
Sometimes I avoid rereading books for the same reason. There was a Summer where Catcher in the Rye felt very important. I'd hate to reread it under my new, adult perspective. I'd prefer to let it linger in nostalgia.
Pick your co-founders by their honesty and humility. No matter what happens, you will build something together that you can all feel proud of.
Going through my fourth start-up now in 15 years. I feel so proud and grateful working with the people I do now. No fights, no stress, just good people who think logically and do their best to support each other.
Personal:
Starting a family is so much more fun than anything I've ever done. Jump into it and let it envelop your being.
This kind of stuff isn't for all apps, but for our use case it was almost too good to be true. We built everything out in about two to three weeks. I don't know how long it would have taken for us to do something similar with true Desktop tooling.
Here's a video of the end result in case anyone in interested...
The code is MIT, so do with it what you want. May be a little bit more complicated then just switching out the build layer, but if you can get something working that's configurable, feel free to send in a PR.
I built it over the summer, funded it through Kickstarter and have slowly been building a nice little client base of recurring revenue. The code itself is open source so it's self-hostable and free, but we provide a quick one-line deploy hosted solution as well.
Probably the most fun bit has been trying to just remove the barrier of troublesome local installation for these kinds of things. Usually people go with PHP because you can just run it everywhere, but that still requires setting up apache/mysql somewhere. We use Firebase and Node, so were able to get the entire package installed through a downloadable app. I think we probably have the fasted installation available for this kind of thing.
I work on it mostly full-time, then design client sites with it on the side.
http://readwrite.com/2009/05/28/google_wave_google_tries_to_...
http://www.theatlantic.com/business/archive/2009/09/google-w...