Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Locked thread
FamDav
Mar 29, 2008

UnfurledSails posted:

I just saw code that iterates over an array recursively. It was surreal

my favorite was someone who wrote all their iteration backwards because they learned that (some old and or bad) c compilers would compiler iterating to 0 more efficiently

also did they use foldl or foldr

Adbot
ADBOT LOVES YOU

FamDav
Mar 29, 2008

Mr SuperAwesome posted:

apparently some chucklefucks at google are making fred@google email addresses lately

(i.e. no TLD or maybe .google is actually the tld or some poo poo)

why? who knows

google is a gtld so makes sense. now I want an @aws :(

FamDav
Mar 29, 2008
a lot of computer janitors outing themselves in this thread right now

feels pretty good that we still live in a society where people are free to be who they are :unsmith:

FamDav
Mar 29, 2008

pram posted:

youre an idiot. do you think AWS is full of windows servers or something lol

the people who own windows on aws are p cool dudes and theres some interesting work there but there is no amount of money that would convince me to touch windows on the regular

Cheekio posted:

I have bad opinions- 3 minutes to start up a linux vm in the cloud isn't a problem.

it really is, because multi-minute startups push complexity up the stack for infrastructure that runs on top of it. driving down inefficiency here will enable new business cases that were economically unfeasible with warm pooling and will also simplify the design of existing systems that do pool resources.

FamDav
Mar 29, 2008
use lightsail OP

FamDav
Mar 29, 2008

eschaton posted:

someone needs to combine message queues with document databases with blockchains

I bet someone like tef or MononcQc could come up with a combined pitch for such a terrible piece of software that could easily raise $texas in angel & VC investment, followed by a nine figgy buyout by MS or Oracle or CA or someone

datomic already exists

FamDav
Mar 29, 2008

Ploft-shell crab posted:

what's wrong with spring?

spring has a huge surface that results in a couple CVEs every year or so. given most people are using it just for 1 or aspects, you're carrying around a lot of exploitable baggage for no good reason.

FamDav
Mar 29, 2008

gonadic io posted:

tps: spent literally the entire work day stepping through spray json internals in intellij's debugger

spray is the one that uses implicits for serializers right

iirc it's slower than everything else out there

FamDav
Mar 29, 2008

Arcsech posted:

whenever a tech thing has "simple" in the name you can assume it is a complex hair all of awfulness

exhibit a: swf
defense counter evidence: sqs

FamDav
Mar 29, 2008

ComradeCosmobot posted:

  • Unlike Eclipse, it didn't seem like you could commit a partially configured project in a way where you won't just clobber other people's classpath and other local settings (e.g. how you can commit a .project file and .externalToolBuilders directory without also committing .classpath and .settings). The .idea directory is all or nothing, which makes distributing custom IDE builder scripts/rules a pain.

why tho

FamDav
Mar 29, 2008

a conversative shaggar post

FamDav
Mar 29, 2008
i know this is the dumbest thing in the world, but i always get really excited when i get to do load testing because i get to spin up a couple thousand instances and i get to see ~big numbers~

FamDav
Mar 29, 2008
Swedish collation is a p good jam band name

FamDav
Mar 29, 2008
Collections.singleton(T t) will infer T based on the return value of the method hth

edit: actually i'm fairly confident that java inference was improved in jdk8 to the point where it would infer it based on the parameter to singleton itself. i know they did a ton of work to improve type inference to make lambdas not a huge shitshow

FamDav fucked around with this message at 03:53 on Sep 6, 2017

FamDav
Mar 29, 2008

cis autodrag posted:

in that example you don't want t though, you want s. it's returning the foo wrapped in a bar inside​ a bar collection that has one member.

You still shouldn't need to specify the type parameter explicitly, see https://ideone.com/DBO6ee

code:
import java.util.*;
import java.lang.*;
import java.io.*;
import java.util.Collections.*;
 
class Foo {
	public String get() {
		return "hello world!";
	}
}
 
class Bar extends Foo {
	@Override
	public String get() {
		return "goodbye world!";
	}
 
}
 
/* Name of the class has to be "Main" only if the class is public. */
class Ideone
{
	public static void main (String[] args) throws java.lang.Exception
	{
		for (Foo s : example()) {
			System.out.println(s.get());
		}
	}
 
	private static Set<Foo> example() {
		final Bar b = new Bar();
		return Collections.singleton(b);
	}
 
}

FamDav
Mar 29, 2008

Shaggar posted:

I'm using dynamodb for simple storage of some basic data and holy poo poo NoSQL is the worst. how can anyone deal with this garbage?

very well if it suits your needs. do you need multi-key transactions, and if so why aren't you using something like aurora?

FamDav
Mar 29, 2008

Shaggar posted:

I just need something to store like 5 columns worth of data in a reliable, shared way and I didn't want to spin up a sql server for it.

so what specific awful stuff are you running into with dynamo?

FamDav
Mar 29, 2008

Shaggar posted:

its just gross to use a schemaless "database". it takes longer to develop with cause you have to manually handle all the validation and enforcement that a schema normally does. you also cant discover a schema so you have to basically document it externally which is totally stupid and error prone.

its not a dynamo db problem, its a schemaless NoSQL problem.

use the dynamodb mapper library, or just use aurora my dude

FamDav
Mar 29, 2008

Shaggar posted:

aurora is MySQL. :barf:

I'm just gonna switch it to azure sql since its not much more expensive

I was going to say use the postgres version but it's still in open preview :(. I personally have no qualms with MySQL but that's more about spending too much time learning it's bs,

FamDav
Mar 29, 2008

Valeyard posted:

you should only use triggers to implement auto increment primary keys for your tables in Oracle

everything else do in your app!!!!!!

please don't use auto-incrementing primary keys. Jesus didn't die for that

FamDav
Mar 29, 2008

Jabor posted:

they don't fit neatly together if you're using them as a clustering key

that's why you either use a datastore that wants you to distribute your data randomly as much as possible, or you use uuids that drop some randomness for better clustering properties.

using auto-incrementing primary keys gives you a false sense of security that you will always have a consistently ordered list of ids, which at some point in the future will no longer be true. better to disabuse yourself of that thinking now rather than later

redleader posted:

guessing keys isn't a thing. either you have access controls in place to prevent someone from looking up record (n + 1) and it doesn't matter, or you don't and you're a clown and you have other, worse vulnerabilities to worry about

yeah exactly. auto-incrementing keys should not be a security risk because you should be authenticating and authorizing every single incoming request against requested resources anyways.

FamDav fucked around with this message at 15:39 on Sep 9, 2017

FamDav
Mar 29, 2008

Shinku ABOOKEN posted:

i was once told that if data isnt sensitive just mark it as deleted without actually deleting it and move on. is this good advice?

you can always reap logically deleted things later. keeping them around aids analysis/BI, and if you need to perform cleanup work asynchronously it lets you keep track of and reconcile incomplete work.

and if data is sensitive you should be encrypting it at rest and only distributing decryption materials to application hosts that have to decrypt it. then you can expose direct access to an isolated replica (you don't want an outage because BI took down your production replicas) of your data to everybody to poke at.

FamDav
Mar 29, 2008

jetbrains had a problem: they had to hold features because they needed to make upgrades worthwhile, and they would rather release features when ready and adopt an evergreen model. they wanted to move to a straight subscription model, but customers who liked having real ownership of the yearly release were mad, so they made it so you could get ownership of a release if you paid for a year. everybody is super happy about it and got what they wanted

except you, the person calling stuff retarded on the internet in 2017

FamDav
Mar 29, 2008

cinci zoo sniper posted:

words can't explain in english the extent of ёбаный стыд this speaks of given that we are running postgre servers amongst other things

how do i pronounce that because this is now my catchphrase tia

FamDav
Mar 29, 2008

meatpotato posted:

am I in the wrong here?

yes because you continue to work there

FamDav
Mar 29, 2008

HoboMan posted:

ctps: just learned about blue-green deployment and i feel like a idiot for not thinking of this myself

it solves basically all of our deployment problems

A couple things to think about when switching to blue-green deployments, especially if you were using rolling deployments before.

don't think that blue-green means "Only new or only old is processing requests" just because you're making the cutover further up the stack via DNS (don't do this for anything external thanks) or loadbalancer. even if you think that you can get a perfect atomic switchover, you still need to make sure you can perform various orderings of old and new requests because you will someday have to rollback a deployment.

be cognizant of the overhead and dependencies necessary to do a blue-green deployment. For every additional thing that is replicated you are dependent on their control systems being available to do a deployment. This means up and has available capacity. Container orchestrators help here because they make it easy to treat your underlying VM fleet as just arbitrary, reusable compute, whereas the VM baking model requires you to provision exactly double excess physical capacity for the explicit purpose of deploying your code.

make sure you're monitoring indicative metrics aggregated to your various fault planes, and know when you have to scale. These are physical things like VM, hypervisor, rack, datacenter (availability zone), and region, as well as logical things like replicated, isolated subsystems. when you were doing rolling deployments you were unintentionally testing how you coped with a (controlled) loss of some % of your resources*; in blue-green you're no longer doing that. its even more important in a blue-green world to knowing when to (auto)scale and to be (automatically) testing the loss of subsets of your infrastructure.

* and if you're hitting scaling issues when you do a rolling deployment you're doubly underscaled. your system should be scaled such that with a single loss at your second largest fault plane (for most that deploy to a single region this is an availability zone) you can still deploy through code without impacting customers. So if when you do a rolling deployment you hit alarms that indicate you're underscaled, you need to not only add enough capacity s.t. you no longer hit those alarms and also add another AZs worth of capacity. This is at least what a correctly scaled service would look like when availability is the be-all-end-all for your service; you might be ok with relying on autoscaling to bring up new capacity or you might be fine with shedding some load for some % of your customers.

FamDav fucked around with this message at 18:03 on Sep 22, 2017

FamDav
Mar 29, 2008

I guess I did make some assumptions, like maybe you never tear the old environment down and you just sit on double capacity. what part was confusing?

FamDav
Mar 29, 2008

HoboMan posted:

the parts about vms and monitoring and scaling. i was just gonna swap staging into prod and vice-versa

HoboMan posted:

like actually swap the boxes instead of running a bunch of scripts in a particular order to properly clone it

oh ok i drive-through window'd you. yeah if you're at the stage where you have two literal boxes and you just want to treat them like a double buffer go hogwild. just make sure none of your tooling assumes that one particular box is always staging or production :)

FamDav
Mar 29, 2008
EDIT: nevermind

FamDav
Mar 29, 2008

i wonder if kids are going to think hashtag is some weird german loanword

FamDav
Mar 29, 2008

jony neuemonic posted:

e/n incoming :toot:

how do i get better at greenfield development? i think i'm pretty good at working with existing stuff and i haven't had much trouble walking into some pretty gnarly projects and getting a handle on things, but whenever i get asked to build something from scratch i panic and deliver (imo) pretty bad work. it's real demoralizing because i don't want to do bad work, and it makes what should be a good opportunity (no more legacy code!) into a huge source of stress.

i get this - especially if you're in a larger company where a lot of the work is extension and addition. some tips

* think backwards. who's the customer of this? what do they actually want? Once you have an idea of what they want, you can start figuring out how to get them it
* Come up with the set of constraints you're working under. Try and really pick the constraints that have to absolutely be fulfilled
* Talk to your coworkers about your idea. Rubber ducking helps but getting a fresh pair of brain hemispheres helps more
* Be conservative. Assume that your group is going to have to own this, and that every new concept you bring in is yet more cognitive load. The clearest example of this is bringing in a new language that nothing else uses or knows.
* Write out a design. Take notes, do some prototyping, come up with your data model and interactions. Write up a design doc that hits these
  1. What is this all for? Often times you know how exactly what you mean when you say "Frothing Bit Reaper" but unsuprisingly a lot of your peers won't. Explaining what this is and why we're doing this is important for context
  2. Remember those constraints from that other bullet? Add these in too. Without those, someone reading your doc will think you're making the wrong decision because they lack the context of the constraints you're operating under.
  3. Go into medium-level detail. Be specific enough that you could hand the doc off to someone else to code it up, but general enough that you haven't literally done all the work

It turns out that "measure twice, cut once" is very applicable to software development, and having a document on hand that explains the what, why, and how of the project is really helpful for the actual implementation of said project

FamDav
Mar 29, 2008

jony neuemonic posted:

e/n incoming :toot:

how do i get better at greenfield development? i think i'm pretty good at working with existing stuff and i haven't had much trouble walking into some pretty gnarly projects and getting a handle on things, but whenever i get asked to build something from scratch i panic and deliver (imo) pretty bad work. it's real demoralizing because i don't want to do bad work, and it makes what should be a good opportunity (no more legacy code!) into a huge source of stress.

i get this - especially if you're in a larger company where a lot of the work is extension and addition. some tips

* think backwards. who's the customer of this? what do they actually want? Once you have an idea of what they want, you can start figuring out how to get them it
* Come up with the set of constraints you're working under. Try and really pick the constraints that have to absolutely be fulfilled
* Talk to your coworkers about your idea. Rubber ducking helps but getting a fresh pair of brain hemispheres helps more
* Be conservative. Assume that your group is going to have to own this, and that every new concept you bring in is yet more cognitive load. The clearest example of this is bringing in a new language that nothing else uses or knows.
* Write out a design. Take notes, do some prototyping, come up with your data model and interactions. Write up a design doc that hits these
  1. What is this all for? Often times you know how exactly what you mean when you say "Frothing Bit Reaper" but unsuprisingly a lot of your peers won't. Explaining what this is and why we're doing this is important for context
  2. Remember those constraints from that other bullet? Add these in too. Without those, someone reading your doc will think you're making the wrong decision because they lack the context of the constraints you're operating under.
  3. Go into medium-level detail. Be specific enough that you could hand the doc off to someone else to code it up, but general enough that you haven't literally done all the work

It turns out that "measure twice, cut once" is very applicable to software development, and having a document on hand that explains the what, why, and how of the project is really helpful for the actual implementation of said project

Adbot
ADBOT LOVES YOU

FamDav
Mar 29, 2008
there might be a new post, we just have to post harder to see it

  • Locked thread