The DBZ chars were my favorites. I have some good memories of playing it for hours with my friends as well. We used to share the same keyboard to play. The first player would use the arrow keys + page up/down home/end etc and the second player would use YGHJ as the arrow keys + QWEASD as the main buttons to play.
I'm left-handed, so I would always take over the left side with WASD for movement - looking back my friends very kind that they let me reconfigure the controls each time.
This thread brought many memories. Like others here, Mugen was my first experience with something that looked/felt like programming. I think I was 11 years old or something.
I remember that I was obsessed with Mugen. I would spend hours downloading chars/stages/screen packs and making my own games combinations. Eventually I started messing around with the source code of the chars/stages etc and started to learn on my own. I never really learned how to build chars properly, but I was good with the screen packs and stages.
Something that I find amusing is that some of the screen packs that I ripped from NeoGeo games and adapted for Mugen 20+ years ago are still available and I guess some people still use them :-)
Two cool works I did was ripping the Real Bout Fatal Fury 2 [1] and KOF'96 [2] screen pack. I even found some videos on YouTube. One of those videos the person who uploaded the demo even gave me the credits after all these years. The second one there was no mention but I know for sure this is my version because of the quirks/bugs :-) I never knew how to properly align the numbers with the texts on the combo/hits sprite messages that are shown during combat haha
I have always used single quotes for Python code since I start working with it. When I started to adopt Black on my projects it indeed felt weird and the code looked unpleasant. But after a while you get used to it.
Some people make the case that it's easier to write single quotes (well, depending on the keyboard format anyway). For keyboards in the US standard you have to hold the Shift key to write a double quote. But the good thing about Black is that you can still write your code using single quote and when you run the command line utility it will fix/normalize the code to use double quotes.
Nowadays I got so used to it that I even write my Python code using double quotes. And looking at Python code using single quotes looks weird/unpleasant for me.
I use single quotes for items that, while technically a string, could be considered a value or symbol. For example:
syslog('debug',"Just opened %s for output",filename)
While there's no semantic difference between single and double quote, in my code base, there is. And if black becomes very popular, why even support single quotes anymore?
This is such a great news. We've been using Black in the company that I work for the past 3 years or so and it was a game changer for code reviews. Hopefully other open source Python/Django projects will follow the lead.
It's 3 am and I'm currently doing just that. It's the moment where the world stops for a couple of hours and no one expects anything from me. My phone is not going to ring, no one is going to send me an email or expect an answer. It's weirdly peaceful
I actually like the Django ORM. Something that I learned working with Django 8+ years is that to use its ORM effectively, you have to play Django's game. Sometimes just by denormalizing a few fields will make some queries/relationships way easier.
At work we have a marketplace engine and a digital wallet/financial app built entirely with Django (100k+ loc) and we don't have a single raw SQL query, everything is done with the Django ORM.
I started my blog about python/django (https://simpleisbetterthancomplex.com) using Jekyll and hosting on Github Pages and it was pretty good to get started because back then I wasn't sure if I would keep it up or not.
After a year or so I migrated to a 5 USD droplet on Digital Ocean (back then GH Pages didn't offer https for custom domains) and integrated with Github webhooks to automate the deployment when pushing new markdown to the main branch.
Over the time it indeed started to degrade. The build time takes almost a minute, but after building the website is just a bunch of static html pages.
Nowadays it is annoying to write new posts because I like to write locally and refresh to browser to check if it's looking good or not. So I would say it degraded for me but for the reader it's still as fast as it was when there was just a couple of posts.
I thought about migrating the blog to something else, but because I used some custom markdown extensions for code highlight and other things, it would be painful to migrate all the blog posts. So I've been postponing it since 2019.
Something similar happened to me when I was using static site generators. In fact one that I was really enjoying even switched programming languages between 1.x and 2.0.
Since that time I look for the people and community behind the project, and try to find signs of stability and long-term care. After that I look at open formats rather than open and flexible architecture-chains. For example, I'd rather use my LibreOffice HTML template and simple PHP controller on a more monolithic (but open) platform than connect a bunch of technologies together to create a build process with a bunch of moving, quickly developing, interdependent parts.
Not sure it's the best answer, but it has worked better to use more monolithic software, even blogging software that's been in steady, if slow development since the early 2000s...
It's a simple injection controller for adding links and markup. Very rough. It doesn't do much about the existing HTML, which I felt was mostly workable, or workaround-able. :-) You can see some output here:
If you use "bundle exec jekyll serve" you shouldn't have too much problems locally as it just rebuilds the pages that change on every save. A minute to deploy the finished version is not terrible by any stretch for a blog IMO.
I wrote my own blogging software, and went through a similar journey. Initially I wrote a simple Perl script which would read all the posts I'd written (as markdown), insert them into a temporary SQLite database, and then using the database I'd generate output.
Having the SQLite database made cooking up views really trivial (so I wrote a plugin to generate /archive, another to write /tags, along with /tags/foo, /tags/bar, etc). But the process was very inefficient.
Towards the end of its life it was taking me 30+ seconds to rebuild from an empty starting point. I dropped the database, rewrote the generator in golang, and made it process as many things in parallel as possible. Now I get my blog rebuilt in a second, or less.
I guess these days most blogs have a standard set of pages, a date-based archive, a tag-cloud, and per-tag indexes, along with RSS feeds for them all. I was over-engineering making it possible to use SQL to make random views across all the posts, but it was still a fun learning experience!
Don’t know about Jekyll but with Hugo you just run hugo server in the Git repo and it will give a a live preview that you can view in the browser, served locally.
It’s very fast.
I have a mockup blog with ~90 pages and it takes 190 ms to generate the whole site.
Jekyll would probably handle that in a few seconds.
But, once you approach two to four or five hundreds, it can quickly add up to a minute or two, making it impractical to say the least.
One solution is to run `jekyll build`, which will just build HTML to a directory, and then just removing old Markdowns and serving those generated HTMLs directly via nginx or something.
I've honestly given up and switched to Ghost, where I don't have to worry about that sort of stuff.
There was a company on here the other day talking about their product, built on top of Docker. I wish I'd bookmarked it.
Their secret sauce is, effectively, partial evaluation in Docker images. They run the code to detect if any of the changes in a layer have side effects that require that layer to be rebuilt (which invariably causes every layer after to be rebuilt)
I mention this because if I'm editing a single page, I would like to be able to test that edit in log(n) time worst case. I can justify that desire. If I'm editing a cross-cutting concern, I'm altering the very fabric of the site and now nlogn seems unavoidable. Also less problematic because hopefully I've learned what works and what doesn't before the cost of failure gets too large. It would be good if these publishing tools had a cause-and-effect map of my code that can avoid boiling the ocean every time.
Correct me if I'm wrong, but don't you have to formally map out all of your inputs and outputs for partial recompilation to work?
I believe the last time I touched make was to fix an exceedingly badly mapped out chain of cause and effect that would consistently compile too much and yet occasionally miss the one thing you actually needed.
Partial evaluation works out the dependencies by evaluating all of the conditional logic and seeing which inputs interact with which outputs.
> Correct me if I'm wrong, but don't you have to formally map out all of your inputs and outputs for partial recompilation to work?
Make needs that information, but that doesn't mean you need to be the one to catalog it. I found this article pretty useful [1]; in a nutshell, many compilation tools (including gcc, clang, and erlc) are happy to write a file that lists the compile time resources they used, and you can use that file to tell Make what the dependencies are. It's a bit meta, so it made my brain hurt a bit, but it can work pretty well, and you can use it with templated rules to really slim down your Makefile.
(I've tested this with GNU Make; don't know if it's workable with BSD Make)
yes because of a bad design decision I made to create a custom "related posts", which is a code that searches all my markdowns to pick the best pages and add to the current page. so even with `--incremental` it take quite some time to regenerate
to be honest jekyll still serves the purpose really well (especially for the reader)
the site is still sitting on an inexpensive entry-level cloud server, it's relatively fast, serves 300k+ page views every month and it give me some passive income
i'm pretty sure that if one uses the framework properly it can still hold on very well
i think what left me with a mixed feeling about static site generators is that it is constantly holding you back whenever you think about growing your website. i ended up building a django api that runs on the same vpc as the blog itself, and i used it to expand some features, like reading from google analytics the total page views for a given blog post, or consuming the disqus api to list the latest comments on the home page. this kind of thing.
managing the posts in static files is quite challenging as the number of posts grows. at some point you will want to change some info, or add a certain metadata and you will need to write a script to walk the _posts dir and edit the files (maybe there's a better way of doing that :P)
I wonder if you could save some time with some caching?
Find all posts related to "django", select the top 3, pin them as the related posts for all django entries? You'd trade out some uniqueness and slightly increased memory usage to gain speed.
(I just got started blogging and found https://github.com/sunainapai/makesite python static site generator worked well for me. Obviously you're probably a bit far in to switch horses by now.)
20 years ago that was my first useful custom CGI script, it took the metadata of the current page and ran a grep for pages with similar tags. Running that was really fast and flexible until I published it and got my first ten simultaneous visitors.
Then I learned about how hard it is to use a cache.
I made goode experiences with Lektor (a static site generator). If you run it locally using "lektor server" you see your page plus admin backend. Once you click (or type) deploy the page gets statically built and copied somewhere via rsync.
You can still have the sources in a git for quick rollbacks.
What I like about lektor over most CMS solutions is that it is more easily adjustable. Basically Jinja2 and python held together with glue
Some static generators like eleventy and Gatsby offer partial builds, only building the new posts etc. which should be considerably faster. Another thing would be to run an empty version of your site with only the text you're working on and when it's done, moving it to the proper site and building it then
Thanks for your Blog! It's a great resource - I love the generic form template and signal blog post.
It is really great and I recommend it to anyone who uses django
Our EC2s seems to be working fine. But RDS is down for us.