|
an almost-good position to be is one where everyone is all "heh, i guess we should make some tests, that would be a good thing, oh well" being actively hostile towards the idea of automated tests: very weird. (i have worked at such a place)
|
# ? Jan 1, 2013 00:30 |
|
|
# ? Jun 11, 2024 08:28 |
|
Cocoa Crispies posted:yeah i update my poo poo and i think heroku updates theirs instead of hashing the string, hash prefix + string, where the prefix is randomly determined on process startup
|
# ? Jan 1, 2013 00:33 |
|
Gazpacho posted:Test... server??? They rewrote the site in Er-haskell.
|
# ? Jan 1, 2013 00:48 |
|
my coworker's conception of a unit test: "it didn't throw an exception or return null, so it must have worked!"
|
# ? Jan 1, 2013 01:13 |
|
Wheany posted:an almost-good position to be is one where everyone is all "heh, i guess we should make some tests, that would be a good thing, oh well" don't ever let an interviewer off with a simple yes/no answer to a dev practice question, ever Gazpacho fucked around with this message at 01:19 on Jan 1, 2013 |
# ? Jan 1, 2013 01:13 |
|
"we have unit tests" = "we have exactly one test per binary, sometimes two"
|
# ? Jan 1, 2013 01:35 |
|
Cocoa Crispies posted:yeah i update my poo poo and i think heroku updates theirs Every hash table ( and hash algo) is theoretically vulnerable to birthday type attacks
|
# ? Jan 1, 2013 01:47 |
|
whoa threaded applications doing asynchronous web requests and shoving arbitrary objects into viewing boxes is so easy c# owns
|
# ? Jan 1, 2013 10:23 |
|
fart bums
|
# ? Jan 1, 2013 10:37 |
|
Malcolm XML posted:Every hash table ( and hash algo) is theoretically vulnerable to birthday type attacks
|
# ? Jan 1, 2013 12:00 |
|
so i had a fun idea for a weekend hack which required writing a plugin for a piece of windows software the code was written in 15 minutes getting it to link correctly with __cdecl and __stdcall static linker hell took over 7 hours and 3 irc channels... developers developers developers
|
# ? Jan 1, 2013 12:06 |
|
oh and the msdn documentation flat out lied
|
# ? Jan 1, 2013 12:06 |
|
Suspicious Dish posted:oh and the msdn documentation flat out lied i scroll straight to the bottom to check for angry community corrections before i do anything.
|
# ? Jan 1, 2013 12:35 |
|
Cocoa Crispies posted:yeah i update my poo poo and i think heroku updates theirs It would possibly be an implementation of cuckoo hashing or a variant of it.
|
# ? Jan 1, 2013 14:17 |
|
Luigi Thirty posted:whoa threaded applications doing asynchronous web requests and shoving arbitrary objects into viewing boxes is so easy c# owns yeah its the best. doing uis with anything else is a hilarious joke.
|
# ? Jan 1, 2013 17:28 |
|
Luigi Thirty posted:whoa threaded applications doing asynchronous web requests and shoving arbitrary objects into viewing boxes is so easy c# owns Shaggar posted:yeah its the best. doing uis with anything else is a hilarious joke. does this also apply to mono
|
# ? Jan 1, 2013 18:02 |
|
Shaggar posted:yeah its the best. doing uis with anything else is a hilarious joke. shaggar what lib do u use for jax-ws axis and cxf both seem to blow
|
# ? Jan 1, 2013 18:03 |
|
MononcQc posted:It would possibly be an implementation of cuckoo hashing or a variant of it. sorta, but nope. that said cuckoo hashing is more resistant to collisions, and probably shows better resistance than just a plain hash with linear probing/chaining. but if you end up using a known hash, an attacker can sorta prepare collisions. even if you use something cryptographically strong, but truncate it or take the modulus to fit it into a (much) smaller number of hashes, the attacker can brute force collisions. so you use a keyed hash - a hash function that takes a key - a bit like salting - so the hash values are unpredictable to an attacker. using a cryptographically strong hash is a very slow way, and many of the existing methods for keying the hash turn out to be vulnerable. the attack presented used a technique called multicollisions, based around differential analysis, which worked on cityhash and murmurhash. it was possible to create collisions independent of this key/seed value. crypto is hard. djb et al have released sip hashing http://en.wikipedia.org/wiki/SipHash as a fast keyed hash with excellent security properties.
|
# ? Jan 1, 2013 18:04 |
|
djb is the raddest
|
# ? Jan 1, 2013 18:30 |
|
HORATIO HORNBLOWER posted:shaggar what lib do u use for jax-ws axis and cxf both seem to blow i use cxf. It works fine, its just not as nice as wcf. If im writing the service, I create the model (including interface) in one maven project and then the service in another. This way if im also writing the client for it, I can just import the model project and cxf can reuse those classes. If im writing the client and dont have the model already, I just use the cxf-codgen maven plugin to generate it.
|
# ? Jan 1, 2013 18:42 |
|
Cocoa Crispies posted:djb is the raddest he is so dreamy
|
# ? Jan 1, 2013 18:48 |
|
so idon't know if you've noticed but the forums changed and all the apps that were scraping it broke this didn't need to happen and wouldn't have happened if somethingawful had an api
|
# ? Jan 1, 2013 19:13 |
|
Win8 Hetro Experie posted:so idon't know if you've noticed but the forums changed and all the apps that were scraping it broke No one cares though
|
# ? Jan 1, 2013 19:39 |
Shaggar posted:i use cxf. It works fine, its just not as nice as wcf. cxf owns
|
|
# ? Jan 1, 2013 19:43 |
|
Cocoa Crispies posted:everyone wants to hire rubyists who know how to test, regardless of if their firm does it or not every tech firm and software consultancy i ever worked with claimed to have test suites and do tdd ... but i have never seen it in action tests either always fail or are hopelessly incomplete or both what do i know, i'm just here to clean up the bit vomit
|
# ? Jan 1, 2013 20:43 |
|
testing - a way of preventing change, and enabling it too. it becomes harder to change your api and behaviour, but you are free to change implementation. for something like sqlite, testing is fantastic. the sql api is somewhat fixed. when you're designing an api, writing your tests first can be like painting yourself into a corner. testing by default causes lots of code duplication, tests that rely on implementation specific behaviour, and everyone's favourite 'put sleep in so the test passes' nondeterminism. testing also seems to be the code programmers have the hardest time throwing away. testing is great but great tests don't come for free.
|
# ? Jan 1, 2013 21:13 |
|
it seems the next year I will write the following post over and over and over again. engineering is about tradeoffs, design is about constraints, and programming is suffering programming is hard. programming in a team is a social problem. it involves people. people are messy. programming is a pop culture, chasing after fads, complete with celebrities and magical recipes to you save us from suffering - by simply by doing what they do, even with different people, and tasks, you will be as successful as them. you could call it algorithmic approach to producing software, but really it's cargo culting. we don't admit this, we pretend we're in a meritocracy. programmers equate popularity, success, and luck with technical skill, and many hope that by being good, they too will be popular, successful and lucky. just like all those elegant languages everyone uses. programming will always suck because code is a product of the culture that builds it. and we are a bunch of whiny, screaming idiots. conway's law. eat it.
|
# ? Jan 1, 2013 21:58 |
|
*bangs on soapbox, cries*
|
# ? Jan 1, 2013 22:09 |
|
quote:put sleep in so the test passes but z/OS systems are really slowwww, we need to allow more time for this thing to deploy never mind the elaborate collection of wrapper functions that your predecessors and colleagues set up to let you do all of this stuff synchronously
|
# ? Jan 1, 2013 22:23 |
|
the scrapers were probs being very brittle about their thing, maybe didn't even have any alternate heuristics as fallbacks, otherwise no show-stoppers or bugs with no workarounds, just minor inconvenience all in all a triumph for the de facto movement for reduced software testing
|
# ? Jan 1, 2013 22:35 |
|
Win8 Hetro Experie posted:the scrapers were probs being very brittle about their thing, maybe didn't even have any alternate heuristics as fallbacks, otherwise no show-stoppers or bugs with no workarounds, just minor inconvenience this is more to do with how lovely it is to have to scrape in the first place and how stupid it is to base an app on scraping data rather than the site administrators being adults and providing an api
|
# ? Jan 1, 2013 22:38 |
|
tef posted:testing - a way of preventing change, and enabling it too. this aligns with my experience especially the tests being the hardest code to throw away my last project's test suite (which took twenty minutes to run and no that wasn't selenium or anything ridiculous) also required its own instantiation and serialization layer because the objects we got from the main codebase weren't guaranteed to be in a valid state when the tests asked for them
|
# ? Jan 1, 2013 22:40 |
|
WHOIS John Galt posted:this is more to do with how lovely it is to have to scrape in the first place and how stupid it is to base an app on scraping data rather than the site administrators being adults and providing an api scraping is ok - if the pages had stable markup on them, the scrapers wouldn't break . what you want isn't an api but a promise not to break an interface. tef fucked around with this message at 22:54 on Jan 1, 2013 |
# ? Jan 1, 2013 22:49 |
|
WHOIS John Galt posted:this aligns with my experience especially the tests being the hardest code to throw away so of course they're going to hold on to those for dear life once they've actually gotten it out of the way to write them, it's not like they want to ever have to go through writing test cases ever again
|
# ? Jan 1, 2013 22:51 |
|
tef posted:scraping is ok - if the pages had api markup on them, the scrapers wouldn't break less. scraping's still poo poo. i'd rather not have to abstract away all the ugly stuff and just have it be a call to a sensible api. the api interface has to stay reasonably static but well duh
|
# ? Jan 1, 2013 22:54 |
|
PrBacterio posted:what'd you expect; after all, tests are the code that the coders enjoyed writing the least, and thus could be the least bothered to rewrite c.f build scripts
|
# ? Jan 1, 2013 22:55 |
Win8 Hetro Experie posted:the scrapers were probs being very brittle about their thing, maybe didn't even have any alternate heuristics as fallbacks, otherwise no show-stoppers or bugs with no workarounds, just minor inconvenience I think people making these apps are more concerned with getting stuff working and features into their hobby project rather than care about some spergy heuristics fallback mechanism for the scraping which wouldn't even be that hard to fix if something changed once in a blue moon. There should be an api, however.
|
|
# ? Jan 1, 2013 22:55 |
|
having to keep a webpage which describes content for a human viewer constant so that a machine can read it is a pretty big horror
|
# ? Jan 1, 2013 22:55 |
|
Jonnty posted:scraping's still poo poo. i'd rather not have to abstract away all the ugly stuff and just have it be a call to a sensible api. the api interface has to stay reasonably static but well duh it is possible to abstract away all the ugly stuff with this approach. a json api would still require this work.
|
# ? Jan 1, 2013 22:56 |
|
|
# ? Jun 11, 2024 08:28 |
tef posted:scraping is ok - if the pages had stable markup on them, the scrapers wouldn't break . Why should the admins need to care that somebody is exploiting the layout of their website, which is purely intended for rendering in a browser, in order to make their app work? That doesn't make any sense. It makes much more sense to have an api which is intended to be used by apps and not browsers and thus it can be maintained separately.
|
|
# ? Jan 1, 2013 23:01 |