116 karma · joined April 3, 2012
I've done a lot of little things in Emacs since. Just minor things to improve my workflows or build up Chief of Staff type information flows.
The repo doesn't quite work yet. Many sharp corners. But the basic idea is there.
pama, I'd be interested in hearing more about how you are using emacs for multiplexing. I'm trying to build up tooling for myself based around file and input workflows and I /really/ don't want to write a text editor and would prefer to stick with emacs.
I have a system that runs on edge services and captures everything to logs through FluentBit. Then there's a cron job that compresses, encrypts, and tries to send the logs to device specific S3 buckets. If the on device logs get too big they start dropping old logs first, with a heuristic for certain logs being more/less important. When devices reconnect to the cloud they start pushing logs as quickly as they can, the cloud infra backfills metrics as they arrive.
Once in S3, triggers start a series of lambdas to decrypt, decompress, analysis. Works well, easy to reason about.
The backend can easily be swapped out for something else. The harder part is the log compress/encrypt/rotate. It's important that you don't treat all logs exactly the same. Some are much more important and should be preserved over others.
Careful with that assumption. While there may be instances where this is true, I've met many veterans that couldn't think outside the small specialty they had become locked into.
Idioms are powerful in that the shape how you think about a solution within a fixed language. They shape your thinking and the shape of your thinking changes what solutions you can conceive of. A veteran that shows interest in a broad range of topics will have more failure experience and will be able to offer better results.
You need to get past the "been told", and start communicating what you want to achieve. It might be too late at this company, but I would bet not, just because these roles are already filled doesn't mean they will stay filled, or that tasks won't outgrow the current holder. Think ahead, and aim for a goal, communicate with every means you have that your ready for that goal.
"Fortune favors the prepared mind." - Louis Pasteur
- A learn X in 7 days book
- A technique driven solution book (cookbook)
- A quick overview of the new hotness library/language/api/framework
- A list of all the functions that you should know
- A reprinting of the half complete wiki documentation of a weekend github toy
- A one off read that you dump in the recycle bin
SICP gives grounding to some of the core problems in computer science. I've returned to it several times, and I always learn something from what I've missed before. Understanding how functions/closures/namespaces/objects all interrelate, how to think in recursion, building higher order programs from pieces, it even covers simple examples of VMs. It's a very strong entry text that has stood the test of time, and is still providing value. Few texts in comp-sci can say the same. SICP does a good job of connecting the theory of comp-sci with a real language without overwhelming the student with absurd language syntax problems.
When any one asks me to recommend a computer book I recommend SICP. Best of all no one has to take my word for it, the book is free. https://mitpress.mit.edu/sicp/ go read it and form an opinion.
Who is SICP not for? If you are at a high level with programming with multiple languages under your belt, most of this would seem like a refresher. If you really "know" VMs then this is going to very low level stuff. If you want a quick read to learn the syntax for scheme this is not the book for you.
"Many eyes" worked for a while but the benefits were lost as scale increased. You are saying that we need to focus on reducing code size. This other extreme is many small unrelated pieces of small functionality, which also breaks down. You would just have a bunch of small programs, some of which are ignored. The complexity remains constant.
Software inspection has shown to have good benefits, this is the heart of "many eyes", the trick is getting coverage. "Many eyes" worked when applied against small enough problems for self organizing groups. As you hint when you say "Modern code is too voluminous for there to be enough eyes to keep Raymond's theory working in practice." Isn't this a management issue? A problem of getting enough people to look into the dark corners and communicate the results?
Luckily there is a very simple thing you can do to hone the first and show the second. Make a game. Don't piddle around with an engine, don't read and talk about how you could do this and that if you were given a chance. Make a game. Make it small and completable. There is not a single thing stopping you from just making a game.
Find a genre you like and make a clone, then extend one area with a new idea. Or a clone that show you understand a specific technical area. Or create a mod for an existing game, hack new functionality into Minecraft, or change a control scheme in Half-Life. Just make something you can show, then show it.
A point though, you will find it easier if you pick an area to specialize in. Saying you want to get into the games industry is like saying you want to play in a band. What instrument do you play?
Most game studios don't hire many generalists without experience. So pick one area that you are willing to work at for 3-5 years and double-down. Then find a way to show 1) you've done your homework at a base level 2) are willing to sit-down and do the work.
for ( var i = 1; i < 16; i++) {
var br = 255 - ((Math.random() * 96) | 0);
for ( var y = 0; y < 16 * 3; y++) {
for ( var x = 0; x < 16; x++) {
...
}
}
}
My interpretation of Bret's idea is that it would be better to have the ability to highlight the section of the texture being written by each section of the loop. It's not the sliders & live editing that are most important it's about linking abstract control into meaning within the learner.