|
TopologicalSorterNonSquareMatrixException
|
# ? Jun 1, 2011 23:19 |
|
|
# ? Apr 27, 2024 21:50 |
|
Biowarfare posted:Today I saw a MySQL database for an old internal webapp. It has one column that contains base64-encoded XML for data. I got one up on that: A clob column with an xml document inside, that gave instructions to the java app that selected that data to use reflection to load the specified class with the specified constructor arguments, which were always HttpServletRequest and something else. The moment I saw that I immediately ripped it out and claimed it "stopped working".
|
# ? Jun 1, 2011 23:34 |
|
Biowarfare posted:Today I saw a MySQL database for an old internal webapp. It has one column that contains base64-encoded XML for data. And I'd put money down if you showed the person who designed that horror NoSQL document style databases, they'd dismiss it outright for some stupid reason.
|
# ? Jun 2, 2011 00:03 |
|
lamentable dustman posted:http://www.google.com/search?&q=site:pastebin.com+mysql_connect+-localhost brb changing every password ever.
|
# ? Jun 2, 2011 00:12 |
|
From the IronPython mailing lists:quote:I have a large RE (223613 chars) that works fine in CPython 2.6, but
|
# ? Jun 2, 2011 00:25 |
|
So wait, he's assuming that every person is going to have a name in his corpus? That seems like a really bad assumption.
|
# ? Jun 2, 2011 00:30 |
|
yaoi prophet posted:So wait, he's assuming that every person is going to have a name in his corpus? That seems like a really bad assumption. He has replied, and I don't know if it excuses him: quote:I'm used to working with a full-featured
|
# ? Jun 2, 2011 00:46 |
|
http://schema.org/docs/gs.htmlcode:
code:
|
# ? Jun 4, 2011 04:22 |
|
I don't see what's so bad about marking up data so that search engines can identify, extract and index it.
|
# ? Jun 4, 2011 06:07 |
|
pseudorandom name posted:I don't see what's so bad about marking up data so that search engines can identify, extract and index it. 1. It's ugly. 2. That's the whole job of a bloody search engine!
|
# ? Jun 4, 2011 08:17 |
|
pokeyman posted:1. It's ugly. quote:2. That's the whole job of a bloody search engine! iow the coding horror is you
|
# ? Jun 4, 2011 08:24 |
|
Brecht posted:Not really. It's extra, meaningful data provided in a canonical, straightforward way. I see HTML as markup that's meant to be almost as human-readable as computer-readable. To my mind, that's why manually editing XML is usually hopeless, and why browsers interpret HTML so leniently. "Extra, meaningful data provided in a canonical, straightforward way" can be, and in this case is, done in an ugly way. quote:If search engines can know the context of data, they get a lot better. I don't see why this is controversial. Nowhere did I say otherwise, your controversy is imagined.
|
# ? Jun 4, 2011 09:04 |
|
pokeyman posted:1. It's ugly. quote:2. That's the whole job of a bloody search engine!
|
# ? Jun 4, 2011 09:19 |
|
1337JiveTurkey posted:Then don't look at the page source.
|
# ? Jun 4, 2011 09:24 |
|
1337JiveTurkey posted:Instead it's separating the data's logical structure from the document's structure so you don't have spans, divs, tables and the like cluttering up the biographical information of a film director. This admirable goal has nothing to do with the posted example, which in fact adds one div and one span that were not present in the original. quote:Removing semantically meaningful data is something that should only be done with a reason. ... Removing metadata which is in a standardized format makes it harder for search engines and other tools to use the remaining data effectively. We're talking about a new specification that adds data. As of a month ago, precisely zero websites were using it. What data is being taken away here? Just as data should be removed only with reason, so should data be added only with reason. There is such a thing as too much.
|
# ? Jun 4, 2011 10:28 |
|
Aleksei Vasiliev posted:writing code without looking at it is some seriously zen poo poo I write like this: code:
|
# ? Jun 4, 2011 10:40 |
|
pseudorandom name posted:I don't see what's so bad about marking up data so that search engines can identify, extract and index it. code:
|
# ? Jun 4, 2011 11:17 |
|
pokeyman posted:Just as data should be removed only with reason, so should data be added only with reason. There is such a thing as too much.
|
# ? Jun 4, 2011 13:35 |
|
pseudorandom name posted:I don't see what's so bad about marking up data so that search engines can identify, extract and index it. It's not just search engines. Enterprise / public sector is also interested in this stuff. You can glean, or attempt to glean a lot of useful information about inflation and prices by screen-scraping information off Tesco.com and the like. And then they change their layout, or add multiples/weights, or add offers, and it turns into a bit of an arms race until you finally say "gently caress it". schema.org and whatnot would be a godsend.
|
# ? Jun 4, 2011 14:58 |
|
Every single time I've seen adding extended attributes to HTML it always ends up terribly. For instance, Drupal is really into FOAF and RDF. So much that every image tag it spits out looks like <img src="beecock.jpg" typeof="foaf:Image" alt="penis"> OF COURSE IT IS TYPEOF IMAGE YOU loving DOLTS, IT IS A loving IMG TAG fffffffffffffclownpensifart
|
# ? Jun 4, 2011 15:18 |
|
Keep in mind that Google already supports three different incompatible syntaxes for this kind of markup, so if anything, schema.org is an improvement over the current situation. It is even more compact than their existing microdata schema, by virtue of "schema.org" being shorter than "data-vocabulary.org".
|
# ? Jun 4, 2011 15:38 |
|
Aleksei Vasiliev posted:writing code without looking at it is some seriously zen poo poo This is generated HTML 99 times out of 100 so apart from reviewing developed code for correctness people won't be looking at it anyhow.
|
# ? Jun 4, 2011 16:48 |
|
pokeyman posted:This admirable goal has nothing to do with the posted example, which in fact adds one div and one span that were not present in the original. code:
quote:We're talking about a new specification that adds data. As of a month ago, precisely zero websites were using it. What data is being taken away here?
|
# ? Jun 4, 2011 17:38 |
|
Brecht posted:So you're saying if I'm writing a movie website, and I know this H3 contains the director's name, signaling that context with a type="director" tag is too much information? Not necessarily, I'm saying adding ten attributes, a div, and a span to signal that context is too much.
|
# ? Jun 4, 2011 19:41 |
|
1337JiveTurkey posted:HTML doesn't do structured data very well and it shows. XML with client-side XSLT does much better in that regard since then you can just have an XML document. HTML does documents very well, and I'm not sure it was ever seriously offered as a language to describe structured data, so why should it do that very well? As you point out, there are better tools for that job. Yet another attempt to bolt some attributes on to HTML and call it a data description language seems wrongheaded. And ugly. <structured data store> + <store to html transformation> will generally be better than HTML for any values of the two variables, if your problem is storing and presenting structured data.
|
# ? Jun 4, 2011 19:47 |
|
gently caress XSLT, seriously.
|
# ? Jun 4, 2011 20:04 |
|
NotShadowStar posted:OF COURSE IT IS TYPEOF IMAGE YOU loving DOLTS, IT IS A loving IMG TAG fffffffffffffclownpensifart Funny you should mention that... code:
|
# ? Jun 5, 2011 06:05 |
|
pokeyman posted:HTML does documents very well, and I'm not sure it was ever seriously offered as a language to describe structured data, so why should it do that very well? As you point out, there are better tools for that job. Yet another attempt to bolt some attributes on to HTML and call it a data description language seems wrongheaded. And ugly. Really in that respect I couldn't agree with you more. HTML really does suck at structuring data in any meaningful manner. If there's any reason people use HTML with microformats at all, it's institutional inertia. My issue is that the second half of <structured data store> + <store to html transformation> should be pushed back as far as possible and the structured data should be available as long as possible. Microformats at least keep some structured data available longer and therefore more useful to tools other than plain old web browsers.
|
# ? Jun 5, 2011 08:41 |
|
I built a poor-man's 'splunk' with PHP that basically dumps form fields into shell_exec(/usr/bin/ssh) to shell into multiple application servers with root ssh keys, grab logs(or anything really), and stream back the aggregated output with optional regex highlighting/filters. Oh and the front end uses a jquery plugin to continuously poll the script every second so users can interactively change logs/servers/search parameters without even hitting submit or anything. Every second for every user I'm spawning like 20 processes across multiple machines. (don't worry - it's cool - I sanitize the user input so they can't tamperdata the request and tail /etc/shadow or something) SiliconCow fucked around with this message at 09:19 on Jun 5, 2011 |
# ? Jun 5, 2011 09:16 |
|
1337JiveTurkey posted:Really in that respect I couldn't agree with you more. HTML really does suck at structuring data in any meaningful manner. HTML has lists, sets and dictionaries. It also has a bunch of other stuff like semantically marked up hyperlinks, what more could you need?
|
# ? Jun 5, 2011 13:20 |
|
Zombywuf posted:HTML has lists, sets and dictionaries. It also has a bunch of other stuff like semantically marked up hyperlinks, what more could you need? Any setup where the structure of data is inherently tied up and munged in with its presentation is pretty sucky. It basically means you have to choose between presenting well-structure data for the benefit of automated systems, or well-presented data for the benefit of humans looking at it, and it's a right pain in the rear end to get both.
|
# ? Jun 5, 2011 15:20 |
|
Jabor posted:Any setup where the structure of data is inherently tied up and munged in with its presentation is pretty sucky. It basically means you have to choose between presenting well-structure data for the benefit of automated systems, or well-presented data for the benefit of humans looking at it, and it's a right pain in the rear end to get both. CSS is for humans.
|
# ? Jun 5, 2011 15:44 |
|
Or since it is a huge pain in the rear end to have text markup also provide the structure and hints to the data in the same document, you could, ya know, provide an alternate method of retrieving documents that more suited to data processing. I believe kids call them 'APIs'
|
# ? Jun 5, 2011 17:36 |
|
NotShadowStar posted:Or since it is a huge pain in the rear end to have text markup also provide the structure and hints to the data in the same document, you could, ya know, provide an alternate method of retrieving documents that more suited to data processing. I believe kids call them 'APIs' Search engines are a very bad place for that, any separation between the human- and machine-targeted representation will be exploited by SEO crooks so they have to read the exact same bytes as a human would at all times. That's the entire driving force behind these embedding systems.
|
# ? Jun 5, 2011 17:43 |
|
NotShadowStar posted:Or since it is a huge pain in the rear end to have text markup also provide the structure and hints to the data in the same document, you could, ya know, provide an alternate method of retrieving documents that more suited to data processing. I believe kids call them 'APIs' I've grabbed data from web scraping non-semantically-marked up content and I've grabbed the same data from APIs. The web scraping has nearly always been easier.
|
# ? Jun 5, 2011 22:16 |
|
Zombywuf posted:I've grabbed data from web scraping non-semantically-marked up content and I've grabbed the same data from APIs. The web scraping has nearly always been easier. This is normally because the human facing content is actually checked and the third party api is not used internally. Also, 'rest api's are often less restful (i.e hateoas) than the website.
|
# ? Jun 6, 2011 04:16 |
|
tef posted:This is normally because the human facing content is actually checked and the third party api is not used internally. Yup, it's also because a website is designed to give you information and an API is usually designed to restrict access to it.
|
# ? Jun 6, 2011 09:01 |
|
Here, have a makefile I wrote about a year ago: http://pastebin.com/CLrVrday I reopened it today because I wanted to see if I could re-use some of the concepts . In my defense, it was for a school project, and I was the only one who was going to be maintaining it for the 4 months it was in use, so I took it as an opportunity to learn all about make. It was also an exercise in creating a non-recursive makefile that could support modules, automatically generate dependency files, and basically automate all the poo poo I needed to do between the dev/test cycles. It was hella fun, and once written it actually made the build process quite convenient. On the other hand, by now I've forgotten more than half the black magic that makes it work, and I die a little inside every time I look at it. I think my favorite line is code:
|
# ? Jun 6, 2011 22:09 |
|
Just fixed the craziest bug, we were getting a web page failing consistently on different browsers (worked in IE, not in FF or Chrome) across multiple servers. It only manifested in the production environment and not in the test environment and centred around this overcomplicated representation of the numbers from 1 to 5:code:
code:
Solution spoilered for those who want to work it out :-) It seems that when comparing two objects that do not have a defined __lt__ python compares the pointers to those objects, which is a completely reasonable arbitrary order. It also seems that objects will usually get assigned pointers in ascending order corresponding to their declaration order. However, minor changes in the memory layout due, for example, to the length of the UserAgent string received from the browser can cause effectively random pointers to be assigned. Hence, consistent failures across browsers. It's been a fun morning.
|
# ? Jun 7, 2011 11:53 |
|
|
# ? Apr 27, 2024 21:50 |
|
Our code is full of stuff like this (we use MooTools):code:
I know this in itself is a small horror, but these things add up. Why the hell not: There is also a shitton of functions that create side-effects for no reason, commented out code (checked in version control), outdated or incomplete comments, global variables, eval() and much more. So poo poo like this: code:
|
# ? Jun 7, 2011 14:18 |