Definitely more successful escapers in Go
5 Likes
I just want to say, it’s very inspiring to see this play out in real time! I’m also a self-taught js hobby coder (though I use MATLAB frequently for work). I enjoy writing the ‘business logic’, but the thought of all the UI layout and styling always kills my grand project ideas. In that regard, I’m curious if anyone tracks other minor OGS feature requests or easy first contributions? Not that I actually have free time, but I can dream…
Tiny note on your goban: the coordinates usually skip the letter “i” (take a look on OGS). But looks great!
Desperately trying to remember my Toki Pona, but… mi toki ike suli e Toki Pona 
6 Likes
ala!! sina toki pona mute!!
sina ken toki e toki pona la, mi pilin pona 
That’s intentional, since this goban display is specifically a reference for the text interface. I like the idea of a text-based SGF editor that provides visual feedback (SGF uses all 52 letters), so that’s what I’ve decided to make ^^ (I’m extremely changeable though so that might not last lol)
The style of including the ‘i’ does bother me too, though, when I see it other places (like on Fox) and I’ve been considering an alternate solution of temporarily formatting SGFs to have more human-readable [letter+number] coordinates for the editing process itself, then exporting it properly… but that is pretty low on my to-do list, especially since I’m not sure whether I’ll even like that solution after implementing it 
I’d like to second this!! Not that I’d have the confidence to attempt anything like that anytime soon, but I could at least take a look
Care to share what those are? 
2 Likes
mi kin li olin e toki pona taso mi toki wile e tenpo suli ike.
1 Like
I learned about the canvas api!! Although I’m thinking I might switch over to SVG; it just seems simpler and less mathy. Anyway since the board is finally normal-looking, I can get back to the fun stuff like syntax highlighting next!
a!! pona mute!!! ni li pona tawa mi.
Maybe I should make this sgf editor interface in toki pona. it will be a hyper-specific special interest tool: a text editor, but only for sgf, and you have to be comfy with vi-like key bindings, and by the way do you know toki pona?
7 Likes
This is looking really cool~
2 Likes
4 Likes
Commit messages do look like that … but… it’s kinda nice if the content of them is better 
You have to ask yourself “what is the purpose of this message?”
Along with that is “who am I writing this commit message for?”
When you know the answer to these questions, you’ll put in the most appropriate content.
If it’s too early in you learning curve to actually know the answer to these questions … typically uou are writing them for a future you, and the purpose is to try to find out where did something go wrong.
So, it should concisely say what specific thing you changed.
It should never (*) say “fixed a couple of bugs”, because each bug fix ideally would be its own commit.
“Made it purple” could be improved just by saying “changed the css to make it purple”, because then you know just reading the commit that this commit did not touch the engine, for example.
(As opposed to “made it purple by updating the rederer”)
(*) “never” in the hypothetical ideal case, in practice we do commit multiple changes at once … but know that when you do it, you make life harder for the future you.
5 Likes
Don’t forget the test cases demonstrating the bugs, in immediately preceding commits!
3 Likes
Has this ever actually happened in the real world?
5 Likes
Sure! I think it’s quite common for those who use a TDD approach.
But I prefer to put test and fix in the same commit
4 Likes
I changed something I think
Idk if you use the command line git, but the -p flag was a game changer for me: git add -p. It shows each patch individually, so I can remember what I did (and sometimes I’ll remove changes I didn’t mean to include)
Another command I use to help keep git history “clean” is git rebase -i. It’s an easy way to go back and change things like commit messages, split or fold commits together etc. Need to be careful when re-writing history, but just wanted to share in case it would come in handy later
5 Likes
I know that Real Codaz ™ use git command line.
But I use SmartGit – Git Client for Windows, macOS, Linux
… much much more relaxing and informative.
Sourcetree used to be both good and free and also supported Macs. It went through some twists and turns where some or all of those were not true, so I ended up using a paid tool. But it may be worth a look.
2 Likes
These are all very helpful responses. Even with my commit messages where I was being a little less goofy, I wasn’t giving as much info as y’all are suggesting. And I really didn’t know the answer to @GreenAsJade’s suggested questions, so to be perfectly honest I guess I wasn’t really sure why I was writing the messages in the first place 
How do test cases work in github? This is a completely new idea to me. You don’t just describe the bug?
This was actually very helpful, even though I didn’t really know at this point:
As far as I can tell, it cycles through all your changes. How do you make custom commit messages for each change, if after it cycles through all the changes, everything has been added? I wound up breaking with ctrl+c for each hunk to do git add 'file_path' git commit -m "message" for each one.
This looks a little visually overwhelming to me. Would you say it’s easier to use in spite of that?
1 Like
As an aside, what are everybody’s feelings on grouping properties in SGF files? I can’t seem to find any style guidelines, but I’ve looked at examples on the red-bean website, OGS, cgoban, goquest, and elsewhere, and it looks like certain things tend to be grouped pretty consistently.
Currently, I’m having my editor group all root properties (seems to be common practice, with 1-2 exceptions among root properties for different editors), time settings (common practice), and Black player info and White player info (this is either uncommon or not done at all; normally, black’s name is grouped with white’s name, then the ranks, or something like that)
There’a bit of a twist, which is that your situation is “sole developer on a project in the early prototyping phases”.
Which means that you likely are only ever commiting to the same branch (master or devel or whatever you called it) in a “straight line”, never creating new branches.
In this situation, I would still use it, because I’m accustomed to it, but I would not say “it’s easier for you”.
But from an “ease” point of view, using the command-line git add and git commit are probably still the “easiest things” if you’re going in a straight line with whole files.
The moment you start doing something else (anything?) like git add -p or git branch … I think it’s easier when you’ve learned the GUI.
These probably come when you’ve released a version, so you need to be able to work on “fixing bugs” and “new features”.
Or when you get another developer on the project
Up till then, commit messages and git tooling are just “good practice” 
2 Likes
But pure command line makes you feel more like an
Ub3r H4ckz0r
Code in Vim in terminal.
Push to git in terminal.
Tmux for tabs.
*Rubs face in satisfied pleasure meme*
2 Likes
Gooplet already disqualified themselves from being an Ub3r H4ckz0r by talking about style guidelines 
You are “supposed to” write a test case (in code) that demonstrates the bug. You’d do that using a test framework, most likely a “unit test framework” … the unit tests framework that you’re already writing your unit tests in, right?
Then when you’ve fixed the bug the test starts passing.
The first way it “works in github” is that unit tests are just code, and they get committed along with everything else.
The more sophisticated way you might make it work is to have a github pipeline run the tests for you every time you commit, and complain at you if you broke something.
If you don’t use a pipeline for this, then you are probably just running the tests manually, by saying something like npm run test
Someone alluded to “TDD” - test driven development. This is where you write the tests before you write the code, and make sure it fails. Then you know you have finished coding when all the tests pass.
Thanks mostly to @benjito, OGS has some tests in Jest . Although nowhere near as many as we ideally would have if everyone were as disciplined as benjito is .
You can get an idea of what they look like here as an example.
Important note: testing (like writing commit messages) is an effort. It helps to know why you would do that in order to judge how much thought and effort to put into it.
The naive reason for writing tests is “so that I know I got the code right”.
Or … if you prefer, there are other quicker or easier-feeling ways (kick the tyres, see if it seems to work ).
A more compelling reason for writing tests tends to be maintenance. They answer the question “how do I know I didn’t break it when I added this feature or fixed this bug, unless I manually test it all again?”
8 Likes