I think you are missing the point, this is offered for perspective, not as a “take”.
I find this tweet insightful because it offered a perspective that I (and it seems like you also) don’t have which is helpful in comprehending the situation.
As a developer, I am not particularly invested nor excited by the announcements but I thought they were fine. I think things may be a bit overhyped but I also enjoyed their products for what they are as a consumer and subscriber.
With that said, to me, from the outside, things seemed to be going fine, maybe even great, over there. So while I understand the words in the reporting (“it’s a disagreement in direction”), I think I lack the perspective to actually understand what that entails, and I thought this was an insightful viewpoint to fill in the perspectives that I didn’t have.
The way this was handled still felt iffy to me but with the perspective I can at least imagine what may have drove people to want to take such drastic actions in the first place.
He is not exactly an insider, but seems broadly aligned/sympathetic/well-connected with the Ilya/researchers faction, his tweet/perspective was a useful proxy into what that split may have felt like internally.
For those of you aren't particularly interested in Ember or frontend development in general, here is a tidbit that may be of interest to you.
While revamping the tutorial[1] to showcase the new features and idioms, I worked on this tool[2] to automate the generation of the tutorial.
Every page of the tutorial you see is the output from markdown source files (like this one[3]) which contains executable instructions for the steps. The build[4] system will run these commands and edits the same way an end-user would, capture the output of the commands and put them in the tutorial. It also takes the screenshots by opening a real browser (via puppeteer) and navigating to the actual app that we are building as part of the tutorial.
All of these ensures that the tutorial content and screenshots are up-to-date with the latest blueprints (the files used by the generators), config files, etc, and that everything really works as-expected. It makes it much easier to maintain and QC the teaching materials, but also servers as a very useful end-to-end smoke test to ensure all the moving pieces in the ecosystem (including external components like npm, node, etc) are all working together.
Right now the tool and the tutorial content are in the same GitHub repo, but the code is actually written to be completely agnostic to Ember.js (or JS even). It just runs shell commands, edit files etc. My intention is to separate out the tool to its standalone thing, so more communities can benefit from this approach.
tl;dr Metal/rust do not give off any smell, and even if they do, they would be odorless. The smell you associate with metal (coins, nails, etc) are actually formed when you touch the metal, at which point the metal acts as a catalyst to speed up oxidation of your skin oils, which forms odorful (?) molecules. So you are really just smelling yourself. The predominant compound attributed to the smell is 1-octen-3-one. The rest of the video is him trying to create and isolate this compound.
Have you read "Learning Rust With Entirely Too Many Linked Lists"[1]? I think it will be quite helpful for these kind of situations. It walks you through all the possible tools in the language that is available to you, and at the end, if you just want to write it how you would in C, you could always do it "unsafely" with raw pointers (which is no worse than C).
Thanks for the feedback! I fixed it in part 2, let me know if it's still an issue for you. Also, I did not know that's how it's implemented in real life (learned it from this thread). Perhaps I should try building that in Web Audio in another series!
I did some of that in part 2! For the most part, it is smart enough to do the right thing for simple operations like cut and inserting rows/columns, however they are indeed some edge cases that it doesn't handle well.
You are definitely correct, this is definitely a bug.
Helix is setup to do the right thing – it already goes through a coercion protocol, we can easily add the encoding check there. We just missed that detail when porting the code, will fix it soon.
I suppose that echoes my point about how system programming in is hard to get right, there are just too many details you have to remember!
This is why having a shared solution like Helix is beneficial. By moving all the unsafe code into a common library, it's more likely that someone will notice the problem and fix it for everyone.
This actually touches on an interesting point I would like to elaborate on. When we say {Helix/Rust/Ruby} is safe, there is an important caveat – {Helix/Rust/Ruby} themselves could of course have bugs. I have definitely experienced segfaults on Ruby myself.
While true, this caveat is not particularly interesting. It is not a slight of hand. Moving code around doesn't magically remove human errors, that's not the point. It's about establishing clear boundaries for responsibility. (This is why unsafe blocks in Rust is great.)
When you get a segfault on Ruby, you know for certain that your code is not the problem. Sure, you might be something weird, but it is part of the contract that the VM is not supposed to crash no matter what you do. As a result, memory safety is just not a thing you have to constantly worry about when programming in Ruby.
It is the same thing as saying JavaScript code on a website "cannot" crash the browser, segfaults in user-space code "cannot" cause a kernel panic or malicious code "cannot" fry your chip. All of these could of course (and do) happen – but from the programmer's perspective, you can work with the assumption that they are not going to happen (and when they do, it's someone else's fault). It's not "cannot" in the "mathematically proven" sense, but it's just a useful abstraction boundary.
Along with that, one of the hidden gems is that dirty tracking now detect inline changes correctly. This means things like JSON/JSONB columns Just Works™ out of the box.
Sorry you felt that way. That project was sponsored by http://adequatehq.com/, so we don't really have much controll over that. Try emailing their marketing department maybe?
Well, in that case, you got any plans this weekend? I'm sure we can find the student something else to work on if you fixed it for us over a weekend ;)
Just quickly – this is the general steps that I loosely follow for fixing bugs in Rails and other codebases that I don't fully understand (i.e. I didn't write the code myself):
1. Reproduce the issue: based on the reporter's comment, try to infer what the "buggy" behaviour is and attempt to reproduce it.
For Rails specifically, it means you need to get the code checked out and get comfortable running it locally. For Active Record and Action Controller bugs, you can use these templates as a starting point to create an isolated reproduction without making an entire app every time.
Sometimes this is not possible (the report is too vague, or you cannot reproduce it). In those cases, ask the OP for clarification and move on.
2. Is this "buggy" behaviour indeed a bug? Sometimes a lot bug report boils down to misunderstanding of the API, using the code in ways that the original author did not intend, or it's otherwise previously reported and closed as "won't fix" for various reasons. This is the part where the research skills you learned in school comes into play. It's not actually that different from, say, doing your research for an essay, you just have to map your skills to slightly different tools/problems.
Read the documentation. Understand the test cases. Get comfortable with using git blame (or the github blame view). Dig deep into the history of the method and figure out why it was added in the first place and for what purpose. Search the issue tracker. Read the previous PRs and issues that led to the code changes you are seeing. Study the commit messages. Ping the originally author (e.g. using @mentions on Github) if you are still unsure.
3. Once you are fairly certain that the reported behaviour is indeed a bug, you need to isolate the root cause. In some cases, after your research in step 2 you would already have a pretty good idea about this. In other cases, it's just like how you debug any other programs.
If you have a reproduction ready from step 1, this is going to be a lot easier. If not, consider starting by writing a failing test.Get a stack trace (e.g. "raise 'omg'"). Set breakpoints (or litter the code with puts statements). Basically you want to follow the input and trace it through the various steps and figure out where did it stop working the way you expect. Sometimes it's easier to do this top-down, sometimes it is easier to go from bottom-up (trace the output back to the input).
Another approach that works well for regressions (i.e. things that stopped working or works differently across releases) is to use git bisect to isolate the commit that broke the behaviour and try to relationship between the change and the bug.
4. If you did the previous step right, you should know how to fix the bug by now. Sometimes it is more difficult than simply reverting the offending change, perhaps because code around it and/or the overall architecture have changed significantly. Or perhaps because the offending commit was introduce to fix another bug, etc, and reverting it would negate the primary purpose of the commit. In those cases, you have to get creative and explore the different ways you can fix the bug. You can always document your findings up to this point and ask someone on github if you're unsure.
5. Once you figured out how to fix the bug, then you have to polish your patch. This means following the guidelines of the project and work it to the level that's acceptable for the project. In Rails, this means that you must write a regression test and follow the various guidelines we have[1]. CHANGELOGs, rebase, squash, commit messages, etc. Whatever it takes to make the project's maintainers happy. Once you did it once and figured out the tools, this would quickly turn into a brainless mechanical task.
6. Submit the patch. This is one of the most important step that everyone overlooks. As a responsible maintainer, I cannot simply accept/merge your changes because you claim that it fixed a bug and you have a passing test to go with it. I need to understand the problem and the code enough to help evaluate if you fix is good – whether it causes other unintended effects elsewhere, could it be simplified, is it going to introduce performance problems, etc. Make that easy for me. Explain the problem. Explain what the code is supposed to do and where you got that from. Explain why you chose to fix it this way. Do you have any doubts/concerns about this that you'd like me to help you figure out? Is there anything else I should be aware of?
If one or more of these things are missing, I'd have to spend time understanding them before I can evaluate your patch. If I don't have time to do that (which is usually the case), I might just have to move on to other stuff and park this for "later". Which is a shame, because you already did all the work to learn about these things. (Of course, I can't just take your words for it either. But at least make it easy for me to verify your findings. Linking the commits/issues/docs in the pull request and/or commit message goes a long way.)
7. Rework your patch. Sometimes you get questions/feedback from the reviewers. Address the concerns either by explaining your motivations or fixing the code as suggested. Rinse and repeat.
* * *
At the end of the day, this is just remapping your problem solving skills (which you are obviously very good at, since you are a programmer :) to the right domain and tools. I hope this helps!
If you are looking for things to do, I suggest that you digest what I just typed a bit and try to incorporate some of the ideas here into the contributing to rails guide[1]. Since you still have questions after reading that, obviously there are room for improvement :) Doing that will help save future wasd time as well as giving you a chance to practice steps 3-7.
I find this tweet insightful because it offered a perspective that I (and it seems like you also) don’t have which is helpful in comprehending the situation.
As a developer, I am not particularly invested nor excited by the announcements but I thought they were fine. I think things may be a bit overhyped but I also enjoyed their products for what they are as a consumer and subscriber.
With that said, to me, from the outside, things seemed to be going fine, maybe even great, over there. So while I understand the words in the reporting (“it’s a disagreement in direction”), I think I lack the perspective to actually understand what that entails, and I thought this was an insightful viewpoint to fill in the perspectives that I didn’t have.
The way this was handled still felt iffy to me but with the perspective I can at least imagine what may have drove people to want to take such drastic actions in the first place.