HN user
I'm seeking a remote job in either FullStack (Backend heavy) or Backend. Check out my CV here: https://letientai.io/cv
Please read the README. The tool turns Markdown into NSPasteboard on Mac, or CF_HTML on Windows, so that when you press Cmd/Ctrl-P onto supported applications (Teams, Word, Google Docs), you get something similar to how Github would display the Markdown in the browser.
Cool. I’ve just publish a tool md2cb to convert markdown to clipboard content (https://news.ycombinator.com/item?id=46896623) using mmdr internally. Totally unaware of this being posted just yesterday.
I need the rendered content, not the plain text HTML. As mentioned in the README, I used pandoc in a previous version of the tool, but its output isn’t good looking for my use case.
Location: Ho Chi Minh City, Vietnam
Remote: Yes
Willing to relocate: No
Technologies: Golang, Java, C++, ReactJS, PostgreSQL, MySQL, Redis, K8S, GKE, CI/CD, Distributed System.
Résumé/CV: https://letientai.io/cv
Email: (find in CV)
I'm looking for either a full-time or contract remote position.
Could you explain more on why we’re doing it wrong?
I'm the OP. I'm working on unify and improving various Distributed Lock implementations for my employer. The first ugly fact is most of our currently implementations are not safe[0], and the second ugly fact, AFAIK, is the safe ones are slow. I'm trying to find something in between, or better.
[0] https://martin.kleppmann.com/2016/02/08/how-to-do-distribute...
Me neither. That show how good vim/neovim is. I hardly see any issue with vim (and a bunch of plugins) during my daily usage.
I tinkered with it a bit and create this code[0] based on a song[1] that I'm learning. I think this tool is cool and has potential, but still need a lot more improvement. At least it needs a way to reduce duplicate in my code :)
Just only watch the intro lecture and I can confidently confirm that this course would be fantastic. However, the professor mentioned that this course is only about processor. Anyone know similar courses/books about filesystem, network, RAM, ....?
If you just want to write better code literally, then consider reading Clean Code[0].
If you want to dive deeper in to Computer Science and become a Software Engineer, then there's a lot more to learn. Here's some short tips:
- Learn a few programming language for their paradism: Java (OOP); Python, Hashkell, Scala (Functional Programming), Rust (memory safety). You don't have to actually work on them, just need to be able to write some algorithm and know their key features.
- Read more code, especially those from high quality projects.
- Experiment a lot. Don't just read articles, blog posts. You have to get your hand dirty.
[0] https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
No. But once in a while, I want to remind us some bit of history. Hopefully inspire new developers, just like how I got the inspirations about old stuff when I first joined HN.
"Read the f* manual!"
Seriously, a lot of questions anwer themselves after I read the related manual. Ever since I got that as a reply on my StackOverflow question, it becomes my motto.
I learn stuff on my own time. If I need more time and the learning phrase is directly related to the my work then I can ask manager to reduce workload. But usually I don't need to ask. I also believe that self-learning in free time is standard expectation for our industry (software). If I run a company later, I would expect the same for my hires.
One of manything that every developers need to read at least once.
Disable mitigations for CPU vulnerabilities
This begs a questions, which type of applications that are ok to disable mitigation?
The correct link for history (at of now) should be:
https://status.gitlab.com/pages/history/5b36dc6502d06804c083...
Above link result in err 500.
I don't have any experience with Pascal cards. My ones are usually the consumer laptops from Dell (Inspiron, Vostro, XPS, Precisions), Lenovo Thinkpad, HP...
Totally agree. For all the non-Mac laptops I've used, nouveau is never a problem. And Ubuntu default setting is pretty good nowadays. I'm suprise that those point make it to a "2020 Edition" list.
Off topic, but I can't stop thinking about "Your lie in April" reading your comment.
* Based on musl libc, busybox and the Linux kernel.
I hope that he won't write commit message like that for project that involve many people. Such log is no helpful (for anyone but him, I guess).
I, on the other hand, try to write technical document to not have to answer the same questions twice. When some one ask me anything that I have a doc cover it, I give them the link. If I don't, I answer, then check and update my doc. That works well for me so far.
I got the opposite experience. People with good technical skills often write dense, skip explaination of topics that they find easy to grasp, assuming the reader also find them easy (which usually is not the case).
In the software industry, these are several problems that prevent the success of written communication culture:
- Most of the dev are not trained for that. They're trained for finding shortcuts (Google, SO), rushing the deadline and fix the code with any solution they can find. People tend to follow the easy path (fix and forget) rather take time to write good docs (code comment, commit message, wiki, ...)
- Some people have good writing skills, some have good technical skills. The ones who are good at both are rare. So some time the docs are confusing, misleading.
- We're lacking good tooling for writing docs. At my work, people prefer to write on Confluence for its inline-comment feature (before, they write in Google docs). But Confluence (and Google docs), IMO, are terrible editors for technical heavy docs and they can't work offline, don't have desktop, can't be used with external editor (I'm a die hard vim fan). Another example: tools for drawing diagram. The plain text solutions (PlainUML, mermaid) I've tried so far don't work well for big diagrams. The non plain text solutions can't be tracked in git, thus defeat the point of single source trust.
I believe if someone can build a product solve my points on tooling, their product will beat Confluence easily. I don't have any ideas to fix the other 2 points, though.
RTFM (as in Read The Fine Manual).
To me, the key for being productivity is understand throughly the "tools" we use: IDE, languages, libraries, framework cli, os, shell,... Read the implementation, the docs, the issue tracker, even the git history if you have time.
When I started to learn vim, I tried many popular distribution without understand each of the plugins they included. And I almost gave up learning vim. It's until I start to read the vim manual, learn the key strokes one by one and then building my own distribution, that's when I really know how to use vim. Even so, I still learn many great things from books like Practical Vim by Drew Neil (on Tmux, there's Tmux 2: Productive Mouse-Free Development)
I think you might already know that, but still shooting here for some quick tips. I don't have any shortcut, just that motto.
_Often my biggest contribution isn’t being the only one who is able to fix something, but being the only one who realises something is fixable._
I feel relatable. At all the placed I've worked, people realize the problem, sometime find the solution, but most of the time, they won't fix it, unless it directly affect their code/project/product. As a result, technical debt keeps bubble up and we have more and more issues.
Right now, the only thing I can do is just to keep fixing issues as I encounter them. But that's for the code, I don't have any solution for the "people" problem.
The extension seems great. But I don't see how would you monetize it from the home page. And if this get popular, how will you pay for the hosting and storage?
2h3 for interview and report, then 2h ~4 for other kind of meetings (sync, feature discussion, 1-1), then some mentoring sessions, 30m * 3-5.
~16h meeting every weeks. To be honest, I'm very much dislike that, but people seems to love talking more than writing detailed docs.
It was an interesting read. But ... why is it on HN home page with just 3 points within 45m?
Definetely a no for me. I also hate seeing commit message littering with emoji and feel like the author is too lazy to find correct words. I also disagree with the "visual cue" advantage, because the emoji looks different per machine/font/terminal/OS. Plain text looks consistent every where.