Whoop whoop. Kanji police!
Blog Home
Building TyNETv5 Pt. 5 - Caramel Isn't My Flavour
in TymoonNexTPosted on Tuesday 18.06.2013 19:57:27 by Shinmera.
So last week I was in Tokyo, which means not much was going on at all. Or rather, so I had planned, but something amazing happened in the meantime. One evening I sat down to take a proper look at Caramel, the library I had intended to use for HTML manipulation/generation. I didn't like it. So then I thought back to what I really wanted. I wanted to have jQuery, but in Lisp. Not thinking too much about it, I opened emacs and wrote a small prototype function that would allow me jQuery like syntax. After about half an hour of twiddling around, I had a (wonky) first solution and it was brilliant.
Kanji - 1361-1376 | Laws and Politeness
in JapanesePosted on Tuesday 18.06.2013 15:25:47 by Shinmera.
Delays!
Kanji - 1345-1360 | Consent of Sickness
in JapanesePosted on Monday 17.06.2013 12:34:20 by Shinmera.
The "more later today" in the previous blog was a lie. I missed it because I had to pack... oh who am I kidding I was just a lazy faggot. Anyway, without further ado...
Here's the ones from yesterday.
Kanji - 1321-1336 | Check With Your Support Beforehand
in JapanesePosted on Friday 07.06.2013 00:14:21 by Shinmera.
Finally another entry. I'm just not feeling like it anymore recently.
Building TyNETv5 Pt. 4 - Blueprints
in TymoonNexTPosted on Tuesday 04.06.2013 17:19:21 by Shinmera.
![]()
Whenever one designs frameworks in which some of the more "core-y" functionality is supposed to be implementable by outside sources, a really difficult problem arises: How do you design the interface? Since this is a core functionality, a lot of other "modules" will depend on it and you can't have those write their functions 20 different ways just to cover all the different versions of one core part. But you also don't want to restrict the interface too much, because that would limit the capability of extending the base functions. It's even more problematic when this pluggable core system is supposed to be general purpose and no strict interface can be defined for each part of the core. So how do we deal with this?
Kanji - 1305-1320 | Correcting the Problem Causes a Worse One
in JapanesePosted on Monday 03.06.2013 22:43:37 by Shinmera.
The first eight were extremely confusing me when I first wrote them up. I can safely blame the fontset for that though, as now that I see it on my workstation it's much clearer what's going on. Regardless, this is still one of the hardest bunch I've had, so my commentary will be sparse at best.
Late oh late as always.
Building TyNETv5 Pt. 3 - Mission Statement
in TymoonNexTPosted on Wednesday 29.05.2013 16:16:35 by Shinmera.
I never went to an actual coding class. I never had a professor teach me anything related to programming. All I know has been out of books, tutorials, specs and discovery. There are a bunch of problems with this approach, most of all that I started out with writing pretty damn bad code, had no idea of how to structure or plan anything and so on. These are all things a good professor could avoid. Regardless, I think this approach also has the benefit of dynamic learning and backstory. That is to say, I can follow back my timeline and see where I've improved and I know why my current style is better than before. I don't just do things because someone told me to.
So last week I was in Tokyo, which means not much was going on at all. Or rather, so I had planned, but something amazing happened in the meantime. One evening I sat down to take a proper look at Caramel, the library I had intended to use for HTML manipulation/generation. I didn't like it. So then I thought back to what I really wanted. I wanted to have jQuery, but in Lisp. Not thinking too much about it, I opened emacs and wrote a small prototype function that would allow me jQuery like syntax. After about half an hour of twiddling around, I had a (wonky) first solution and it was brilliant.
I never went to an actual coding class. I never had a professor teach me anything related to programming. All I know has been out of books, tutorials, specs and discovery. There are a bunch of problems with this approach, most of all that I started out with writing pretty damn bad code, had no idea of how to structure or plan anything and so on. These are all things a good professor could avoid. Regardless, I think this approach also has the benefit of dynamic learning and backstory. That is to say, I can follow back my timeline and see where I've improved and I know why my current style is better than before. I don't just do things because someone told me to.