Side rant: I just cannot believe people praising 'Unit Test'-ing. Fellow programmers, how exactly do you unit test a method / function which draws something on the canvas for example? You assert that it doesn't break the code?! I see some really talented people out there who write unit test as proof that their code works without issues, that it's awesome and it cooks eggs and bacon etc. They write such laughable test…
> Fellow programmers, how exactly do you unit test a method / function which draws something on the canvas for example?
We don't. Canvas drawing routines are hopefully unit-tested already by their authors. We do write unit tests for calculations and logic to make sure that the values passed to some canvas function are as expected.
Overwrite functions in dynamic languages (like JavaScript) with some "dump all arguments code" and call/return the original function, to get a quick glimpse in the code. Though this doesn't work with closures without some extra eval tricks.
I wrote some simple bash scripts around git which allow me to very quickly identify the most frequently-edited files, the most recently-edited files, the largest files, etc. https://github.com/gilesbowkett/rewind it's for assessing a project on day one, when you join, especially for "rescue mission" consulting. it's most useful for large projects. the idea is, you need to know as much as possible right away. so you r…
Hmm... this is an interesting project. No License info though.
I am surprised how few younger programmers use a debugger these days.
Maybe this is just my lack of experience speaking, but I find debuggers incredibly difficult to use when dealing with interactive software (which is most software I work on). Hitting a breakpoint freezes my interaction unless I configure it to print something, and configuring it to break conditionally requires knowing some obscure incantations that I can never remember off the top of my head (and that in turn require…
Not sure if you know this but if you're in javascript you can just drop a 'debugger;' statement anywhere in your code and it will function as a breakpoint.
Maybe this is just my lack of experience speaking, but I find debuggers incredibly difficult to use when dealing with interactive software (which is most software I work on). Hitting a breakpoint freezes my interaction unless I configure it to print something, and configuring it to break conditionally requires knowing some obscure incantations that I can never remember off the top of my head (and that in turn require…
Not sure if you know this but if you're in javascript you can just drop a 'debugger;' statement anywhere in your code and it will function as a breakpoint.
Ah yes, I should have mentioned that this is coming from a native application developer!
Take the extreme programming approach. Don't try to familiarize yourself with a new codebase all at once. Start small. Work on a small ticket. It will, organically, help you assimilate what's happening.
I wrote some simple bash scripts around git which allow me to very quickly identify the most frequently-edited files, the most recently-edited files, the largest files, etc. https://github.com/gilesbowkett/rewind it's for assessing a project on day one, when you join, especially for "rescue mission" consulting. it's most useful for large projects. the idea is, you need to know as much as possible right away. so you r…
Hmm... this is an interesting project. No License info though.
Added a pull request to use git ls-tree for filenames so you only check stuff in the repo, instead of find. Hopefully it will end up on an open source license of some sort.
Side rant: I just cannot believe people praising 'Unit Test'-ing. Fellow programmers, how exactly do you unit test a method / function which draws something on the canvas for example? You assert that it doesn't break the code?! I see some really talented people out there who write unit test as proof that their code works without issues, that it's awesome and it cooks eggs and bacon etc. They write such laughable test…
Some unit testing might be a joke, but not all unit testing. If you have small units-of-work they should be tested, or at least testable. Integration testing often makes a lot more sense, though.
I believe I'm in the minority, but I think unit tests are nearly universally worthless - exceptions being those for well defined APIs (eg math). Good unit tests must have an independent oracle of truth or else you aren't testing anything. As a practical matter you should only write tests for code that materially impacts the business (or you are just wasting everyone's time ). Instead of writing regression or integration tests, which are hard (hence the need for testing), people absent mindedly write unit tests and point at code coverage.
Thanks for sharing. I often get lost in large projects. Blindly jumping around is quite inefficient and frustrating. How hard do you think it is to write a tool to draw dependencies map for a specific language? May be there're built-in code analyzing tools in compilers for popular languages that I'm not aware of?
For golang std lib, since packages have no circular deps, it can be automatically drawn out like this: http://lonnie.io/gostd/dagvis/ If you write your project that even has no circular deps among files and all files are small (like me in https://github.com/h8liu/e8vm ), you can draw the similar graph but at a much finer granularity, like this: http://8k.lonnie.io/
wow! What did you use to make these? It looks awesome!