p-lang thread: (now (have you (problems two)))

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »

spongeh: Mar 22, 2009; BREADAGRAM OF PROTECTION

Nomnom Cookie posted:

that guy is editing one script because he doesn't know any better. it's also A Thing to concatenate and minify the js for a page, it speeds js up lol

efb

javascript execution speed is not at all affected by combining/minifying scripts. the speedup is because you're not getting the overhead of taking down and negotiating new http requests. this has nothing to do w/ the language itself.

# ? Oct 8, 2013 17:16

Adbot: ADBOT LOVES YOU

# ? May 23, 2024 15:46

Notorious b.s.d.: Jan 25, 2003; by Reene

Tiny Bug Child posted:

how many people work here? probably about 30-40 full timers. idk it's started to hit the point where i don't actually know everyone who works over in the spain office

1 mil / mo on 40 ftes ain't shabby

i'm in the wrong business

# ? Oct 8, 2013 17:22

Notorious b.s.d.: Jan 25, 2003; by Reene

spongeh posted:

javascript execution speed is not at all affected by combining/minifying scripts. the speedup is because you're not getting the overhead of taking down and negotiating new http requests. this has nothing to do w/ the language itself.

the js language standard is what mandates the lovely serial downloads and serial loads

all other http resources are pulled in parallel

# ? Oct 8, 2013 17:22

Posting Principle: Dec 10, 2011; by Ralp

Notorious b.s.d. posted:

the js language standard is what mandates the lovely serial downloads and serial loads

all other http resources are pulled in parallel

nope

# ? Oct 8, 2013 17:25

Notorious b.s.d.: Jan 25, 2003; by Reene

Posting Principle posted:

nope

please explain to me how you can implement the standards-mandated dom without the lovely serial loads

i'm all ears about why mozilla and chrome choose to be slow as gently caress for no reason

# ? Oct 8, 2013 17:28

Shaggar: Apr 26, 2006

javascripts are pulled the same way all other resources are, its the execution that's done sequentially. the reason people minify their javascript libraries is because they are laughably huge and its less bandwidth for the server

# ? Oct 8, 2013 17:28

Posting Principle: Dec 10, 2011; by Ralp

the reason is that http spec says you shouldnt have more than 2 simultaneous persistent connections

# ? Oct 8, 2013 17:30

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Notorious b.s.d. posted:

public, static, and main are all fuckin fine. get a grip. they're well-specified, they are well-understood by users coming from other languages, and they provide useful features

it was a joke, that was what pollyanna as blubbering about in the coding horrors thread after reading babby's first java tutorial for 3 minutes

# ? Oct 8, 2013 17:31

Notorious b.s.d.: Jan 25, 2003; by Reene

Posting Principle posted:

the reason is that http spec says you shouldnt have more than 2 simultaneous persistent connections

no browser hews to this hth

# ? Oct 8, 2013 17:32

Nomnom Cookie: Aug 30, 2009

spongeh posted:

javascript execution speed is not at all affected by combining/minifying scripts. the speedup is because you're not getting the overhead of taking down and negotiating new http requests. this has nothing to do w/ the language itself.

startup time is affected and that's what I mean. it's part of speed.

although i wouldn't be surprised if minified js ran faster too

# ? Oct 8, 2013 17:44

Nomnom Cookie: Aug 30, 2009

Notorious b.s.d. posted:

public, static, and main are all fuckin fine. get a grip. they're well-specified, they are well-understood by users coming from other languages, and they provide useful features

if we want to nitpick bad keywords, the fuckup is the omission of "final" from your list. it means at least six different things based on context. let's see if i can name them (i will miss some i guarantee it, even w/ google to help)

final classes cannot be subclassed. easy peasy. like "sealed' in c# except re-using a keyword

final methods cannot be overriden

final variables are actually const variables

final variables in an inner class do something completely different: they modify scope to permit the enclosing class to use the variables

final primitive variables are const, but they're also synchronized. or inlined. depending on how the compiler feels that day.

final arrays are never const in the C sense, they're heap allocated objects even if they are primitive arrays

final parameters make them const. because otherwise java params are non-const. lol

idk i mean yes that's dumb and stupid. but it shouldn't be costing anyone days of work (jar hell) or severely limiting the types you can create (no structs, type erasure). also final and const are different, final is const pointer only

# ? Oct 8, 2013 17:49

Shaggar: Apr 26, 2006

jar hell isn't a thing if you're using maven and u aren't using maven ur a moron.
type erasure is not really a big deal and is only slightly annoying when you want to do something that's probably 90% of the time a bad idea.

# ? Oct 8, 2013 17:52

Notorious b.s.d.: Jan 25, 2003; by Reene

Shaggar posted:

jar hell isn't a thing if you're using maven and u aren't using maven ur a moron.
type erasure is not really a big deal and is only slightly annoying when you want to do something that's probably 90% of the time a bad idea.

jar hell is a thing in j2ee, because classloader ordering/behavior is poorly specified

but if you use j2ee you probably hate your job for lots of other reasons

# ? Oct 8, 2013 17:54

Notorious b.s.d.: Jan 25, 2003; by Reene

Nomnom Cookie posted:

idk i mean yes that's dumb and stupid. but it shouldn't be costing anyone days of work (jar hell) or severely limiting the types you can create (no structs, type erasure). also final and const are different, final is const pointer only

yeah having final mean a bunch of things is not going to cost you a lot of time over your career. but it's dumb and stupid and hard to learn, and java was meant to be clear and simple and easy to learn

# ? Oct 8, 2013 17:55

Shaggar: Apr 26, 2006

its not a problem unless ur doing dumb things or the server is buggy.

# ? Oct 8, 2013 17:55

trex eaterofcadrs: Jun 17, 2005; My lack of understanding is only exceeded by my lack of concern.

always use osgi

# ? Oct 8, 2013 17:59

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

# ? Oct 8, 2013 18:09

Nomnom Cookie: Aug 30, 2009

Shaggar posted:

jar hell isn't a thing if you're using maven and u aren't using maven ur a moron.
type erasure is not really a big deal and is only slightly annoying when you want to do something that's probably 90% of the time a bad idea.

it's a thing if not all of your dependencies are properly mavenized, and it's not always feasible to mavenize them yourself

# ? Oct 8, 2013 18:11

Vanadium: Jan 8, 2005

ooh can i play

# ? Oct 8, 2013 18:21

Shaggar: Apr 26, 2006

Nomnom Cookie posted:

it's a thing if not all of your dependencies are properly mavenized, and it's not always feasible to mavenize them yourself

ya it is

# ? Oct 8, 2013 18:22

Bloody: Mar 3, 2013

get better deps

# ? Oct 8, 2013 18:24

Shaggar: Apr 26, 2006

if you've got stuff you know is on the server, add it as provided in ur pom (or better yet create a pom w/ all the provideds listed and make that a reusable dependency).

if the stuff is custom crap, shove it into nexus

# ? Oct 8, 2013 18:27

Opinion Haver: Apr 9, 2007

pom pom wei wei wei

# ? Oct 8, 2013 18:27

trex eaterofcadrs: Jun 17, 2005; My lack of understanding is only exceeded by my lack of concern.

Nomnom Cookie posted:

it's a thing if not all of your dependencies are properly mavenized, and it's not always feasible to mavenize them yourself

it's really not that hard,

if you have the source, just add a pom
if you only have a jar/war/ear, just use the nexus to upload the artifact directly, with a bespoke pom

make sure your versioning scheme matches theirs, and what i always do is put my org's group name and extend the artifact name to include their group name (or what i would assume is their group name), spring does this

so like, if you have jar "lovely thing" from oracle and it's version 1.2.3, and your org is something awful the gav should be com.somethingawful/com.oracle.lovely-thing/1.2.3

# ? Oct 8, 2013 18:29

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Vanadium posted:

[#]unrelated but i forgot how to do numbered lists in bbcode

list=1

burps
farts
pianos

I was going to use a pre for the formatting but lol, it renders even in a pre block:

pre:

burps
farts
pianos

thanks radium

# ? Oct 8, 2013 18:30

Nomnom Cookie: Aug 30, 2009

trex eaterofcadrs posted:

it's really not that hard,

if you have the source, just add a pom
if you only have a jar/war/ear, just use the nexus to upload the artifact directly, with a bespoke pom

make sure your versioning scheme matches theirs, and what i always do is put my org's group name and extend the artifact name to include their group name (or what i would assume is their group name), spring does this

so like, if you have jar "lovely thing" from oracle and it's version 1.2.3, and your org is something awful the gav should be com.somethingawful/com.oracle.lovely-thing/1.2.3

which works great until a coworker decides to run his artisanal hadoop jar on my classpath and everything is hosed and i have to either support his attempts to fix it or take over packaging his mapreduce jobs

i'm not saying it's a problem with no solutions, i'm saying it's a problem and you have to solve it. it sucks even if you know what you're doing. it sucks to look at a list of 300+ jars to spot conflicts. it sucks integrating dependencies that bundle their deps, have old deps, and don't have an unbundled option

p.s. hadoop packaging is so terrible. its just the worst

# ? Oct 8, 2013 18:49

Shaggar: Apr 26, 2006

the solution is use maven and fire the people who don't use the solution

# ? Oct 8, 2013 19:08

Zlodo: Nov 25, 2006

PleasingFungus posted:

list=1

burps

farts

pianos

I was going to use a pre for the formatting but lol, it renders even in a pre block:
pre:
burps
farts
pianos
thanks radium

Use code instead of pre

code:

[list=1][*]burps
[*]farts
[*]pianos[/list=1]

# ? Oct 8, 2013 19:16

Notorious b.s.d.: Jan 25, 2003; by Reene

Nomnom Cookie posted:

which works great until a coworker decides to run his artisanal hadoop jar on my classpath and everything is hosed and i have to either support his attempts to fix it or take over packaging his mapreduce jobs

i'm not saying it's a problem with no solutions, i'm saying it's a problem and you have to solve it. it sucks even if you know what you're doing. it sucks to look at a list of 300+ jars to spot conflicts. it sucks integrating dependencies that bundle their deps, have old deps, and don't have an unbundled option

p.s. hadoop packaging is so terrible. its just the worst

yeah so your problem is not that mavenizing an unmavenized jar is hard. it's definitely not hard. it takes about 60 seconds.

no the problem is that you have some rear end in a top hat jars that bundled their deps. which means you have to unpack and repack the jar. which is not that hard in itself, it just makes me really, really angry when i have to do it

# ? Oct 8, 2013 19:18

Notorious b.s.d.: Jan 25, 2003; by Reene

the only thing worse than bundling your deps in the jar is loving it up with OneJar

that way you can have bundled deps AND a hijacked classloader that ignores your classpath

# ? Oct 8, 2013 19:19

Bloody: Mar 3, 2013

Nomnom Cookie posted:

p.s. hadoop is so terrible. its just the worst

# ? Oct 8, 2013 19:32

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

Nomnom Cookie posted:

which works great until a coworker decides to run his artisanal hadoop jar on my classpath and everything is hosed and i have to either support his attempts to fix it or take over packaging his mapreduce jobs

i thought hodapp was just something you ran on the mapred cluster and not on your workstation

# ? Oct 8, 2013 19:59

Nomnom Cookie: Aug 30, 2009

Cocoa Crispies posted:

i thought hodapp was just something you ran on the mapred cluster and not on your workstation

ok technically they took my classpath and shoved ALL OF IT into hadoop

at oldjob i started thinking the only sane thing was to make everything a WAR and run it inside tomcat. this is what newjob does

# ? Oct 8, 2013 20:14

Nomnom Cookie: Aug 30, 2009

Notorious b.s.d. posted:

yeah so your problem is not that mavenizing an unmavenized jar is hard. it's definitely not hard. it takes about 60 seconds.

no the problem is that you have some rear end in a top hat jars that bundled their deps. which means you have to unpack and repack the jar. which is not that hard in itself, it just makes me really, really angry when i have to do it

oh yeah if its a little jar mavenizing it is ez. the problems come from projects like hadoop that just assume they own the classpath and bundle up a whole bunch of poo poo and provide zero guidance on what deps are actually necessary and what you can remove. storm does this too

it's not like this is a new problem, servlets addressed it a long rear end time ago by giving each war its own classloader. but open sores is poop from a butt

# ? Oct 8, 2013 20:19

Shaggar: Apr 26, 2006

so either run each hadoop in its own jvm or run it inside its own container. ez pz problem solved.

# ? Oct 8, 2013 20:38

Notorious b.s.d.: Jan 25, 2003; by Reene

Nomnom Cookie posted:

oh yeah if its a little jar mavenizing it is ez. the problems come from projects like hadoop that just assume they own the classpath and bundle up a whole bunch of poo poo and provide zero guidance on what deps are actually necessary and what you can remove. storm does this too

storm and scalding are both way worse than hadoop

a normal java application has properties files, config files, and shell scripts to configure and boot the drat thing. in the worst case, you get like jetty, where the properties/config/shell just launches start.jar, which relaunches the jvm

storm and scalding turn this poo poo on their head. storm uses python scripts + yaml config + environment variables to launch. scalding uses ruby. it's impossible to turn a storm or scalding app into a normal deployable thing; no matter what you do you're gonna come back to their wretched scripting

yeah we know java has 10 years of deployment tooling but we thought "python storm.py deploy-my-poo poo" was somehow better

# ? Oct 8, 2013 20:44

Notorious b.s.d.: Jan 25, 2003; by Reene

also at least the storm python scripts are halfway readable

scalding is so bad i just couldn't get it to run on my desktop; it like wanted scala 2.8 and ruby 1.8 and prayer. and there were no usable docs just example code, which of course requires scalding to already be working

it's like they just dumped somebody's source tree + readme.md to github and called it done

# ? Oct 8, 2013 20:45

Shaggar: Apr 26, 2006

theres probably a maven plugin that handles generating the startup scripts and prob windows java service wrapper installation scripts too

# ? Oct 8, 2013 20:46

Shaggar: Apr 26, 2006

Examine your problem.

Is the problem solved by using maven/maven plugins?

if the answer is no, your problem is you.

# ? Oct 8, 2013 20:48

Adbot: ADBOT LOVES YOU

# ? May 23, 2024 15:46

Workaday Wizard: Oct 23, 2009; by Pragmatica

Notorious b.s.d. posted:

also at least the storm python scripts are halfway readable

scalding is so bad i just couldn't get it to run on my desktop; it like wanted scala 2.8 and ruby 1.8 and prayer. and there were no usable docs just example code, which of course requires scalding to already be working

it's like they just dumped somebody's source tree + readme.md to github and called it done

sounds real bad

e: woah big

# ? Oct 8, 2013 20:49

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »