Hi Peter! For H1B visa holders, is there any way to start a company and remain in charge (whether as CEO or not)? From what I find online you can only be employed as a H1B holder, but if I start a company I would want to have full control of it.
I'm interested in building something with this to aid my own French learning. Would love to read your findings if you end up posting it somewhere like twitter/blog!
- captures a tree tab structure (inspired by Tree Style Tab)
- has a text-heavy interface
- is keyboard driven (inspired by Vim)
- keeps data local or syncs to a GitHub gist (no server)
- exports to Markdown
I often hear from others they need something similar, and I thought about finishing it up so others can use it. But my fear is that I made too many personal design choices that nobody else would like, and changing those choices would make myself less happy (but surely make it easier for others to use).
I have thought about building a vocabulary learning tool for learning Japanese on top of Apple Dictionary. My idea is simple: user collects dicitionary items and the tool offers lookup / spaced-repetition.
However, I'm concerned that the dictionary is copyrighted. Is there any precedent that says whether such a tool would be legal/illegal?
Does anyone have recommendation for static site hosting with simple server-side analytics? The only thing I can find is Netlify Analytics, but $9/mo is too much for hosting a few pages of OSS project documentations.
If there's no complex interactivity achieveable only through JS, I prefer to ship sites with plain HTML/CSS, so I don't really like to use any client-side analytics. And yes – I can live without all the fancy features to track and profile my visitors.
I don't want to host by myself either, since I enjoy using a simple git push to deploy my site.
If you are interested in creative coding but don't know where to start, me and my friend are running Codecember, a month-long challenge to do one code sketch a day: https://codecember.ink
We pick simple sketches & recreate them in p5.js as a learning process. Eventually you remix the sketches with your ideas to create something original.
Our prompts exposes a diverse variety of generative artwork, none of which are too difficult to recreate. Join us for the second half!
Nice work! The other day I was doing a SVG renderer for Shiki[0] (a code syntax highlighter), but found no easy way to measure font width/height (SVG needs absolute positioning) in Node.js. The only library that does that records fonts' metadata in the package source[1].
I ended up using puppeteer[2]. Would love to switch to `skia-canvas`, however `ctx.measureFont` doesn't seem to work correctly yet. Measuring cap `M` produces positive `actualBoundingBoxDescent`, although `M` should sit comfortably on top of baseline.
One take away for me was: Language designers & compiler writers today need to consider editor support as one of their goals.
On the top page there's another thread about rust-analyzer vs RLS. What Aleksey said[0] about RLS that "[RLS's] current architecture is not a good foundation for a perfect IDE long-term," feels similar to my coworker's conclusion in her effort to provide better editor support for PHP[1].
Parsers for compiling code into machine-executables vs parsers to serve LSP responses have different tradeoffs. For example, Anders mentioned TS parser need to have good error-recovery, can respond with completions/errors when one file changes inside a thousand-files-project. I vaguely remember TS had a goal to provide completions in < 50ms and errors in <150ms. Such goals are hard to achieve as after-thought. If your core compiler doesn't do error recovery, such as PHP, you need someone to write a new compiler from scratch for a language server implementation. If tools such as RLS rely on compiler to dump all JSON metadata and figure out LSP responses[0], it's too slow for editors.
TS's good editor support doesn't come free. I think one of the most under-appreciated achievement of TS is how it took editor support seriously and designed its compiler infrastructure to do it well. That's why I don't believe in those hot-new-web-languages that try to take over TS by designing a better type system. TS brought the average developer's expectation of a language to having fast completion, fast error reporting, editor autofix, F2 to rename and renaming-a-file-in-editor-to-update-all-references. It's 2020 and people aren't going back to write code like in Notepad.
> Let's start with something simple, like syntax highlighting.
I built a syntax highlighter, Shiki, that allows you to use any theme from VS Code to color your code [0]. It works great with Node now as a static website generator plugin, but with some effort you can run it all in client side as well. TypeScript's new handbook is using Shiki [1].
I can't really believe how it's 2019 and Medium and Slack still can't syntax highlight code snippets.
> Obviously with log parsing you don’t get as much information as a JavaScript-heavy, Google Analytics-style system. There’s no screen sizes, no time-on-page metrics, etc. But that’s okay for me!
This also bypasses Ad blocker. In the case you have a large percentage of technical audience (who presumably would have Ad blocker installed) this log can be way more accurate than GA.
However this still requires setting up the image on a third-party server. I would really love it if GitHub pages or Netlify can provide some simple server-side tracking. It doesn't match GA but in some cases that's all I need.
Well, here are two things that have been brought up many times:
1. Required fields on new issues. Has been requested since 2016[0].
2. Better issue search.
Open Source projects face a lot of issues. It's good to talk about them, but some GitHub can solve some GitHub can't. I'd be much happier to see these problem addressed instead of learning about updating my profile status[1].
Currently when a project becomes popular the issues easily drown the author. As the communication portal between OSS authors and users, GitHub can and should give OSS authors more power.
I like everything about Observable but the editing experience. In 2018 no one wants to write code like writing txt files.
Is there any plan to adopt Language Server Protocol so at least users could get auto completions? But with the custom syntaxes to JS I guess Observable can't just use plain TypeScript Language Server.
I'm not sure what's complex. Adding one more option "Triaging" here[0] doesn't seem complex.
I'm working at VS Code and now we are trying to make a bot that would add a label if someone (from a whitelist) types `/label bug` (same for marking duplicates). The fact that we have to go this far for letting community contributors assign labels to issues is more maddening to me.
I hope GitHub could add some features to help Open Source maintainers. Allow adding contributors with issue triaging privileges is an obvious one. Required fields (link to repro, software version) could be really helpful too.
Currently people have to work around these issues in awkward ways, like creating a whole organization just to grant issue triaging privileges or redirecting people off GitHub for filing issues with required fields [0]. Those workarounds run into limits quickly.
Now when I see any new product I look for a pledge to not get acquired like PostHaven[0]. Otherwise I simply refuse to use it. Sparrow, Mailbox, Inbox...Have been burnt too many times.
