Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API

From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "army private-army"
-
What if the long term goal of @trogus and @dfox is to create a developer army, hell bent on the destruction of project managers and clients everywhere (except the cool ones).
I mean I'm not saying it's a bad thing. Just wanted to... You know.... Raise some attention.3 -
Oh I have quite a few.
#1 a BASH script automating ~70% of all our team's work back in my sysadmin days. It was like a Swiss army knife. You could even do `ScriptName INC_number fix` to fix a handful of types of issues automagically! Or `ScriptName server_name healthcheck` to run HW and SW healthchecks. Or things like `ScriptName server_name hw fix` to run HW diags, discover faulty parts, schedule a maintenance timeframe, raise a change request to the appropriate DC and inform service owners by automatically chasing them for CHNG approvals. Not to mention you could `ScriptName -l "serv1 serv2 serv3 ..." doSomething` and similar shit. I am VERY proud of this util. Employee liked it as well and got me awarded. Bought a nice set of Swarowski earrings for my wife with that award :)
#2 a JAVA sort-of-lib - a ModelMapper - able to map two data structures with a single util method call. Defining datamodels like https://github.com/netikras/... (note the @ModelTransform anno) and mapping them to my DTOs like https://github.com/netikras/... .
#3 a @RestTemplate annptation processor / code generator. Basically this dummy class https://github.com/netikras/... will be a template for a REST endpoint. My anno processor will read that class at compile-time and build: a producer (a Controller with all the mappings, correct data types, etc.) and a consumer (a class with the same methods as the template, except when called these methods will actually make the required data transformations and make a REST call to the producer and return the API response object to the caller) as a .jar library. Sort of a custom swagger, just a lil different :)
I had #2 and #3 opensourced but accidentally pushed my nexus password to gitlab. Ever since my utils are a private repo :/3 -
Any other Screeps players here?
for the people running into a "Screeps is not defined":
Screeps is a MMO RTS where you code your "army" to do stuff in Javascript (a la NodeJS).
Code how your harvesters should behave, how your soldiers should behave, how your builders should behave etc. etc.
So far, it is quite a fun game, tho my (Intel Nehalem based) laptop has issues handling it (thanks to a awfully slow GPU...) so it's difficult to play for me at the moment (I'm on holiday, my home PC is a LOT faster).
It costs about 15 euro on steam, and if you're into this stuff, it's well worth it.
Just make sure you finish the tutorial first... I didn't and I regretted it when I bought the game (it's a huge pain in the buttocks to get started if you don't understand the API and such).
Currently just playing on my own localhosted private server to discover how the game works and such, but will be setting up a public server later down the road to play with others.
Tho it would be nice if Screeps would allow for "team-based" gameplay as well so it'll be slightly harder for early players to bully the newer ones.2 -
My mom was a data analyst in the Army when I was a kid. At around 10 I remember her teaching me batch scripting. Just seeing code and working with the machine was amazing to me and since then I've tried to learn all I could.
I spent a long time not doing this kind of work and finally in the last few years decided to follow that passion. So for me 20 years of my own private passion has turned into a skilled and profitable career I wasn't expecting.3 -
A thing that I am annoyed that people are getting wrong is security by obscurity.
You have heard of it and being told it is bad. It is so bad that it alone is a counter argument. Let me set you straight:
>>>Security by obscurity is the best security you will ever have<<<
There is an asterisk: It is probably not right for your business. But that is for the end.
Security by obscurity means to hide something away. Most security is based on hiding. You hide your private key or your password or whatever other secret there is. If you had a 2048 long sequence of port knocking, that would be fine, too.. Or it would be fine if it wasn't observable. You could write this down in your documentation and it wouldn't be security by obscurity. It would just be security. Weird, but fine.
The real meat of obscurity is: No one knows that there is someone. The server you port knock looks like a harmless server, but suddenly has an open port to a bad application for an IP, but only if that IP went to 25 other ports first.
In the animal kingdom, there are different survival strategies. One of them is being an apex predator or at least so big and lumbering that no predator wants a piece of you. That's our security. It is upstream security. It is the state.
But what is the rest of the animal kingdom going to do? Well, run away. That works. Not being caught. And those not fast enough? Hide! Just be invisible to the predators. They cannot triple check every leaf and expect to be done with the tree before starving. That's security by obscurity. Or hide in the group. Zebras. Easy to see, hard to track in the group. Look like everyone else.
There is a reason why drug smugglers don't have vaults in the carry-on. Arrive at the customs and just refuse to open the vault. If the vault is good enough. Nope, they lack the upstream security by the state. The state is there enemy, so they need obscurity rather than cryptographic safety.
And so, for a private person, having a port knocking solution or disguising a service as another service is a great idea.
Every cryptography course happily admits that the moment they can catch you physically, cryptography is useless. They also teach you about steganography. But they omit to tell you that obscurity is the second best solution to having a stronger army when you cannot rely on your state as upstream security.
Why did I say, not a good idea for companies?
1. It is self-defeating, since you have to tell it to all employees using it. A shared secret is no secret. And therefore it cannot be documented.
2. It makes working with different servers so much harder if there is a special procedure for all of them to access them. Even if it were documented. (See 1.)
3. You're a company, you are advertising your services. How to hide that you run them?
Do you see how those are not security relevant questions? Those are implementation relevant questions.
Here is an example:
Should you have your admins log into servers as normal users before elevating to root or is that just obscurity? Well, not for security purposes. Because that foothold is so bad, if compromised, it makes little difference. It is for logging purposes, so we have a better server log who logged in. Not only always root. But if our log could differentiate by the used private key, there is no issue with that.
If it is your private stuff, be creative. Hide it. Important skill. And it is not either, or. Encrypt it your backup, then hide it. Port knock, then required an elliptic curve private key to authenticate.
It is a lot of fun, if nothing else. Don't do it with your company. Downsides are too big. Cheaper to hire lawyers if needed.2