Readit NewsThe structure is (using [dirname] notation for directories)
[Repo Root]
...git and github files, READMEs...
[Flappy Bird]
... project files, keystore, build.bat ...
[App]
[build]
... I'm ok with tools making a mess here as long as outputs is tidy ...
[outputs/apk]
..the actual .apk
[src]
[main] this seems a little off, main contains libs and resources
Android_Manifest.xml Yep ok, I'll rant about that later, that's its own thing
[assets] all good
[res] Wait what? that's like a synonym for assets, (but for a different layer)
[libs] Hang on, these are .so files. built libs should be in the build dir
[jni] This looks like what src or src/main should have had inside it
I'd Shuffle it around to make [Flappy Bird] contain [main] and [build]. move [libs] to [build/libs] rename [jni] to [src].
If you had an architecture like that then the one-true-build-system should be a command line tool that you can point at [main] and it does what [Flappy bird]/build.bat does only with auto detection of the installed tools, optional config file overrides, optional commandline overrides.
AndroidManifest is another issue entirely I'd like something that invisibly converted something sane to XML and I'd never see it again, but I'll grin and bear it. A decent validator and maybe I'd like a standalone AndroidManifest editor that knew what everything did and could provide appropriate boilerplate.
After typing this up (mostly as organizing my thoughts), I actually think you could have a relatively painless way to make Android Apps.
Any widely used modern editor/IDE will have plugins to do the same thing.
> having some custom scripts that read ctags and could tab-complete keywords from our large codebase
Contextual completion as offered by modern IDEs or language servers is vastly superior to Ctags, and you don't have to home-cook anything to get it working.
> and having the same editor on our embedded servers and VMs as on dev machines
That's what SSHFS is for. No need to limit yourself to whatever happens to be installed on the remote machine. You don't even have to copy config files around.
(sshfs is not a direct substitute for being able to quickly interact with a remote environment)
> having some custom scripts that read ctags and could tab-complete keywords from our large codebase
for clarity i meant that I had a completion in the terminal when not in the editor to quickly jump to a tag in a file. `vim -t <keyword>`. i could be in a terminal, execute a remote command on a machine, know what I wanted to look at next and quickly go there without much effort. And again, other people were productive without doing this. these were just my tools and i liked them.
When I "program", 95% of what I do is read documentation and other technical resources, conceptualize what I want to happen, and construct the corresponding logic flow, while trying to anticipate potential problems and corner cases. In other words, most of what I do doesn't involve touching the keyboard at all.
If Vim magically tripled the speed at which I'm able to edit text, I doubt it would have a noticeable impact on my overall productivity. In fact, even if you gave me a brain-computer interface that allowed me to manipulate text at the speed of thought, it wouldn't matter much. I touch-type at around 70 WPM, which is very average, but if I two-finger typed at 15 WPM instead I would still be able to produce exactly as much code as I do today.
Simply put, text manipulation is not at all a productivity bottleneck for me. I need much more time for thinking about code than I need for writing it.
Is this really unusual? How do people operate for whom Vim gives a productivity boost? Does code just flow from their brains into their fingers? I don't get it.
There were people at the company who were more efficient than me using Sublime + mouse, but I was less efficient using Sublime.
(but really the biggest reason I use vim as a slow and sloppy typer and not a computer person is, hotkeys make my hands hurt, I've managed to avoid any RSI or pains like this, and I like vim better than vim keybindings in other editors.)
other productivity gains not related to typing were the search/replace in vim, embedded terminal, and being in and staying in a terminal made it easier and quicker to switch to scripty things, searching or reformatting files etc
A wise man once said: It's best if you drink water. If you drink one coke a week, then it's best you drink a regular one with sugar. But if it's more and you can't help yourself, then at least drink diet coke instead of regular coke.
#run compile_to_binary("name_of_binary");
main :: () {
// ...
}
#import "base"; // my own library that has 'compile_to_binary'
The above code '#run's any procedure at compile-time (in this case 'compile_to_binary' which is defined in the library I imported). That procedure (really a hygienic macro) configures my 'workspace' to compile down to a 'name_of_binary' executable in the current directory. Any third-party libraries I've imported will be linked against automatically as well.
To do this without a dedicated procedure, just put this in the same file as 'main':
#run {
options: Build_Options_During_Compile;
options.do_output = true;
options.output_executable_name = "name_of_binary";
set_build_options_dc(options);
}
main :: () {
print("This is all I need to build a project\n");
}
#import "Basic";
#import "SDL"; // or whatever...
jai above_file.jai
The best part is neither of these systems are a requirement to build your project. Running the compiler against a Jai file will do everything I do with my own system (I just like having the ability to configure it in code).
Jai has been a breath of fresh air in terms of "just let me write code," so I highly recommend it if you can get in the beta.
What is complicated is receiving the response, that different services sometimes operate in regions and sometimes operate globally (but have a us-east-1 endpoint) and that some return XML, some return JSON, some return a gzipped response and some not, and much of it I haven't found documentation for and have had to figure out how to wrap calls to different services to be able to interact with them in a sensible manner.
But aside from a brief 3 years as a C developer (embedded hardware product) I've never been close to being one. Because when I was coming out of university seven years ago with a good CV and projects I could competently talk about, and I _could_ do the whiteboard segments, somehow I ... couldn't do them the way they wanted? And they, the very sparsely spread places with listings at the time, were offering no money for a new grad to somehow make their way across the country to interview, only to be offered a low salary (the C job I got was at the risk of a £180 train ticket three weeks before I would have had nowhere to live).
Now? I maintain a fleet of Wordpress sites for a digital agency for a modest £40k a year as the company's sole "someone who knows anything about Linux" person. Because my coworkers are lovely, my boss doesn't stress about anything and lets us flex our time and the clients are nice. Money is tight and definitely less than my skillset but going through the hoops of the "clever" side of the industry to be well paid and well stressed sounds daunting. There was no nurture for anyone not conforming to a very specific template which shows its face on the ranty side of Twitter.
Deleted Comment
I wasn't able to deliver packages but I was too mesmerized to be mad about that. Beautiful game. Kudos.
Edit: I did figure it out and completed all the deliveries. So many potential. It reminds me a bit of Sky by thatgamecompany
Edit 2: for the author, I noticed several players approached me and tried to communicate. Please explore games like Journey (thatgamecompany) to see different ways people communicate without chatting. People can help each other, veterans can guide newbies all without using words. Every time I met a player in the game back in the days, they sent me a heartfelt message.
[0] https://i.redd.it/jv2yw7uqmu3e1.png