For what it's worth, this is actually one of the strong-points of helix. Many of the key-bindings display an unobtrusive list of follow-up actions that close without any lag if you already know what you're looking for. It's worth trying specifically because of how much effort has gone into being easier to pick up and get started with than something like vanilla vim.
On the flip side, it's taken me a long time to break my skimming habits and read slowly when I'm a novice in a new area. Especially with math or software engineering, it's often necessary to stop at each word I don't understand, unpack it, and gradually build a scaffolding for myself. This is very slow, but it pays dividends extremely quickly.
As a rule of thumb, it seems like skimming is useful if one already have a good familiarity with a subject and the content is slotting into an existing mental framework. However, when that's not the case, skimming gives me the feeling that I've learned something without much real progress.
I think it's great to play to one's strengths, but it's also true that what people perceive as "quick thinking" is often the result of very large amounts of practice. More specifically, people I know who are good at the types of skills described at the beginning of the article (mental math, witty responses, remembering facts, playing badminton to a high level) probably have a knack for them, but there are also types of underlying skills that aren't obvious to someone who hasn't spent a lot of time practicing the activity in question. I'll take two skills that I'm familiar with as cases in point: mental math and tennis (adjacent to badminton).
For mental math, there are all sorts of tricks that allow one to transform the problem into one with fewer values to hold in memory (for instance [1]). There are also lots of different patterns that allow shortcuts in calculation. The more of these one knows (kind of like facts in a trivia contest), the simpler many sorts of mental math problems become. And the more one has practiced, the faster one is at applying them. This is not to say that there aren't people who are exceptionally gifted, but it's also possible to be perceived as "quick-witted" by actually doing a lot of slow thinking ahead of time.
With tennis, sometimes it seems like players have exceptional reaction times (At the highest level, they certainly do!), but one learns over time to move to different areas of the court preemptively based on what the opponent is likely to do. This often shortens the distance one has to run by a step or two, which makes a pretty big difference in reaching difficult balls. Also, time spent practicing with better players who hit harder gradually changes one's perception of ball speed and one's ability to follow the ball all the way to the racket. It's like one's eyes get better, somehow. None of these perceptual changes or positioning habits happen overnight, but with enough stacked skills practiced over time, a person's reaction time appears to get faster even if their absolute reaction time hasn't improved.
Of course there are people with a higher skill ceiling than others, but I also think people write themselves off as being hopeless at something, choose not to practice, and then conclude that they are unsuited to the skill without having better understood what the road to "good" actually looks like.
This course is one of my favorite sets of notes and exercises to make the theory of 3D reconstruction from images more practical. I especially appreciate that the scaffolding code and images that support the problem sets are available and well-packaged. That means that unlike some online courses, I've been able to get enough tangible feedback to know whether my mental model is correct.
The course also uses Hartley and Zisserman's book, Multiple View Geometry in Computer Vision. While it's a very comprehensive book that's definitely worth owning, it's also kind of intimidating for self-learners. The course and the book together help to balance each other.
There are probably lots of weird shapes used in practice, but the nice thing about game design is that you get to build the mesh directly instead of making your best guess at what kind of surface unconnected points ought to represent. Mapping to a sphere is definitely pretty restrictive.
I'd imagine most are either planar or complex/undefined. Most meshes in gamedev probably aren't even closed with a unique inside/outside; just "pile of triangles".
If this aids your argument, nearly All video game models that I tried to convert to 3D printing STL files were non-manifold.
I think this logically follows from your statement, and it made fixing the stl files necessary otherwise the printer would switch to imaginary coordinates halfway thru the print and since the printer is mechanically restricted the print does a good impression of an Escher painting.
For the last few years, I've been working on a self-checkout product similar to Mashgin that quickly identifies the items people place on a platform. I've really enjoyed work that involves stereo cameras and lidar, 3D scanning, surface reconstruction, and geometry more generally. I also get a lot of satisfaction from building libraries and other dev tools that make some of the more math-heavy tasks easier for non-experts. For more of a flavor of the kinds of work I especially enjoy, take a look at this article: https://andrews.wiki/spherical-mesh.
I've also been a manager and a tech lead, and I try very hard to establish priorities for my team that are simultaneously good for the product and good for the people who work towards them.
I'm currently looking into robotics companies, but anything that involves perception is welcome.
Curiosity, what do you mean by "Southern Pennsylvania"?
I am from Pennsylvania, attended Penn State, and I have lived in many different towns throughout the state including south-central ones. I've befriended yinzers and yousers. But I have never heard "Southern Pennsylvania" before.
My mind boggles. Is this some variation on "Little Washington"? Is this a Philadelphian way to simplify "Southeastern" and to therefore ignore, "SEPTA" notwithstanding, the hundreds of miles west of Philly? Are you near Chambersburg? Is this some way to describe commuting suburbs into northern Maryland? Is this some play on the Mason-Dixon line and you are actually in Maryland?
Stepping away from this particular case, what does a well-executed Associate's degree for computer science look like? At top-tier schools (at least in the US, which is all I'm familiar with), there's an expectation that most of the incoming students already have a reasonable familiarity with the basics of programming, but that's unreasonable to expect for everyone entering college. And since it's useful to have some practical familiarity with programming before taking an algorithms class, it further seems like getting some sort of software engineering two-year degree would be a good use of time before either entering the workforce or deciding to cover some theory in the following two years (algorithms, computer architecture, compilers, etc.).
What would a two-year degree like that cover? A variety of useful languages plus their most common frameworks? Basic data structures? Common industry tools (git, CI, docker, linux)? Even though it doesn't fit very naturally into the US college experience, I'm wondering if a well-executed two-year "bootcamp" (for lack of a better term) could actually fill a gap that exists right now. It at least allows people to choose if they're interested in theoretical computer science or not. Theory is quite helpful, but not everyone wants/needs to opt in to math, proofs, etc.
Finland has a model of high school alternate vocational programs. But standards and funding are so low it is mostly useless, places seem mostly day cares for students.
Applied science universities however are not as rigorous as traditional universities, but do offer suitable degrees with practise in actual software development with lighter load on pure computer science or advanced topics.
In the US there are technical high schools in many states. Not sure exactly what the curriculum looks like. I'm sure it involves programming but probably not CS topics.
I just started working on an engine for turn-based table-top games like Dominion, 7 Wonders, Catan, etc.
During university, I spent some time working on an AI agent to play Dominion, but a very large part of the work was building a way to simulate the game.
The goals are:
- Develop an engine that's efficient enough to use in simulations (for training AI agents or analyzing the game).
- Still emit events that can be used to visualize the current state of the game when real people are playing.
- Create primitives that are easy to distribute across a network for remote players/agents.
Some people live in their editor and occasionally drop into a shell. I've personally found a lot less friction in doing the opposite. Live in the shell, and occasionally drop into your editor.
I used to think that it would be better to have a lot of scripting and automation built into my editor, but there are so many well-built, connect-able tools already available in a unix shell that it's usually easier to write scripts in that context, instead. There are often easy ways to pull the outputs of those scripts into your editor or use your editor as a thin, pass-thru layer to run shell scripts on certain selected bits of text in a file.
This is mostly how I work as well, and has the advantage that when I need to poke around on servers and appliances on which I do not have my vim setup, I can still use a lot of my regular “tricks” because they are shell-based.
Sure, sure, I do miss tpope’s surround and repeat plugins, but I have shell muscle memory and am happy(ish).
+1 .. Came to say the same thing. My favorite IDE is the Unix shell. Multiple great editors to pick from, multiple and very flexible ways to hook all your tools together. Easy to use on remote systems. All of it free software.
