Unholy Alliances



  • I've pointed out a few rather unholy alliances (PHP+GTK, Node+Webkit) and others have been mentioned (PHP+Qt)

    What other technology abominations have been created that fuse totally inappropriate things together?



  • I once wrote an IRC bot in PHP.

    Basically, any use of PHP for any purpose other than displaying a crappy website is guaranteed to be cringe-worthy.



  • Call me a contrarian, but Node.js + WebKit seems like an obvious match to me.

    Most of the worst abominations I've worked with were the result of people not using obvious matches and coding their own. For example, Creation Engine + Papyrus. There's literally zero reason they couldn't have used Lua or JavaScript instead, and both Lua and JS are... sane. (Ok, fine, you can argue about JS, but it's much more sane than Papyrus.)

    But no. Using an established scripting language to write scripts for your game engine is a terrible idea. Especially Lua, which was built expressly for this exact purpose. Better to invent our own mutant offshoot of VB and subject people to that.



  • I would love to understand how you come to the conclusion that Node+Webkit is a good idea, I really would.



  • @Arantor said:

    I would love to understand how you come to the conclusion that Node+Webkit is a good idea, I really would.

    Twist your brain around the other direction. Take something like Xojo or RunRev, a cross-platform programming language hooked into a GUI interface editor. Now imagine how you'd write such a thing if you wanted to make the underlying language JavaScript instead of a Basic variant. What would you need to make that product work?



  • Java SE + PowerPC 32bit platform (+ Bash + Ruby)



  • I have a Perl web app. That's a WTF alone.



  • Ok, I just finished typing out a huge lecture on why I'm a-ok with node.js, so I'm not doing that again. I'll just reiterate that node.js has NOTHING to do with webkit. It's a wrapper around V8 engine, so you can run it outside the browser. That's it.



  • How about VBA + Office?

    Take a business package meant for non-programmers.
    Put a programming language in it.
    The result?
    A glass-footed wobbly pile of fail on top of which a good chunk of the world's financial systems reside.

    I don't think you can get more unholy than that.



  • PHP + MUMPS

    Body is invalid; try to be a little more descriptive



  • Classic ASP JS + Classic ASP VB

    on the same page


  • Discourse touched me in a no-no place

    The most inappropriate technology combination I ever encountered was some weirdo who used Tcl for his OS on custom hardware. I still don't know what he was smoking when he came up with that. I mean, I've seen quite a few people using it for the higher-level management layers, but only this one person was mad enough to do the buffer and memory management code in it (even PHP would probably be a better choice due to differences in language semantics). It's mad! Mad, I tell you.



  • People running PHP on a Windows server. I don't get the WAMP stack at all; if you've already gone to the expense of Windows licensing, use a proper software stack.



  • @Keith said:

    People running PHP on a Windows server. I don't get the WAMP stack at all; if you've already gone to the expense of Windows licensing, use a proper software stack.

    FTFY



  • @ben_lubar said:

    FTFY

    I'm quite happy with running PHP on Linux, but I wouldn't want to sully a Windows server with it. PHP can be a perfectly good development tool if you use a suitable framework. It's ideal for projects that don't want to be tied into to the cost and licensing aspects of Windows.


  • 🚽 Regular

    At least the guy is partially conscious of what he's doing:

    Be worried, be very worried.</blokquote>


  • I LIKE IT!


  • 🚽 Regular

    I noticed.



  • I would have linked the Robocop video again but I couldn't find it. I love the idea of Node+PHP because I have stuff I want to do that relies on long lived connections and that stuff in PHP is virtually untenable.


  • I survived the hour long Uno hand

    I did it in perl. And then wrote an XML-RPC api so it can communicate with a website built on PHP.



  • .NET with Oracle is pretty nasty, I did some projects in college around that. It's not like SQL Server where a .NET application can talk to a SQL Server free of charge. You gotta have gigabytes worth of Oracle crap installed on the client system just to connect to an Oracle instance from your application. Even worse, .NET has the relatively sane method of storing database connection information in an app.config file right next to the executable where it's easy to find and, if necessary, modify. But with Oracle, there's some hidden configuration file elsewhere on the system.

    Desktop software connecting to SQL Server = easy and sane. Desktop software connecting to Oracle = please shoot me in the face YESTERDAY.



  • Now do that from an Excel/VBA macro.



  • Anything with Oracle is bad. Simply because Oracle is bad itself.



  • @chubertdev said:

    Anything with Oracle is bad. Simply because Oracle is bad itself.

    By extension the same now applies to MySQL. WordPress is fucked on two counts.


  • BINNED

    @Arantor said:

    By extension the same now applies to MySQL. WordPress is fucked on two counts.

    Pushing to move our app to Postgres atm.
    Problem: I don't know shit about Postgres.
    Bigger problem: I'm the resident "expert" :facepalm:



  • I'm using Postgres. It's great. Do it.

    You'll find postgres has several special data types you wouldn't normally find. Here's a quick map of how not to get screwed.

    • Arrays: Use them. They rock.
    • Enums: Don't use them. If you're doing anything like migrations, you won't be able to script all the changes you might need. They need more work.
    • JSON: They seemed fine, until I tried comparing two records and it turned out you can't compare JSON values. They are working full steam on extending and fixing JSON support, but so far, this is a deal breaker for me.

  • BINNED

    Since you brought it up - any advantage to storing JSON messages as JSON data type if the only purpose is to save a history of JSON messages? I will need some place to store missed notifications (which are usually sent through a websocket) so the user can receive those that were triggered while they were logged off.

    I could cache them in something simpler like a text file or a small SQLite DB, but seems like an overkill to me since there already are database connections in place.



  • The advantage of JSON type is you can access the data inside using built-in functions (usable in queries, for example). If you don't need that, then better use text. At least if you're using PostgreSQL up to 9.3 (there are indications 9.4 might improve things).


  • BINNED

    Figured it was something like that, but wasn't sure. Most likely going to go for text in this case then. Thanks.



  • Reminds me of the numbers/phone/zip code thing. If you're not doing anything with it other than storing, use text. Especially if you need to use malformed values.


  • BINNED

    @chubertdev said:

    Reminds me of the numbers/phone/zip code thing. If you're not doing anything with it other than storing, use text. Especially if you need to use malformed values.

    One of the features I have is a searchable phonebook, including the address. Also, I have to parse phone numbers and split them into country code + area code + actual number from both realtime data and user input.

    It's... fun, to say the least.



  • I demand town code.



  • @chubertdev said:

    Reminds me of the numbers/phone/zip code thing. If you're not doing anything with it other than storing, use text. Especially if you need to use malformed values

    Actually, in this case, the correct thing to do would be to store JSON type, because that gives you an additional layer of data validation. It's just that the comparison thing is currently a deal-breaker (at least it was for me).

    I don't blame them for stalling on this front. Let's say you have these two json-s:

       { "name": "Jack", "male": true }
    
       { "male": true, "name": "Jack" }
    

    Are these two the same json-s? Going by the pure data, they are. Going by their string representation, they are different. What do you do to keep both the same string you entered in and be able to compare the entire JSON tree in a general case? No trivial at all.


  • BINNED

    @chubertdev said:

    I demand town code.

    Does not apply for the current market, and no idea if there is a difference in phone charges wherever you use it. So I don't care, really.

    Country codes are enough of a mess already, overlapping in certain places so you have to drill down into international area codes (See: US and Canada).

    @cartman82 said:

    Actually, in this case, the correct thing to do would be to store JSON type, because that gives you an additional layer of data validation.

    That is a fair point. I mean, the JSON is generated by me (and using built-in functions of course, no manual string concatenation mumbo-jumbo) so I can be fairly certain it's ok but hey, might as well I guess.

    @cartman82 said:

    It's just that the compassion thing is currently a deal-breaker (at least it was for me).

    At the moment, I just need the stuff stored somewhere so any relevant notifications that were missed can be delivered to the user once he logs in.

    I was thinking of a more lightweight storage for those messages, but it seems silly to me to add another layer of complexity when I have a perfectly good database already there and being used.


  • 🚽 Regular

    @cartman82 said:

    What do you do to keep both the same string you entered in and be able to compare the entire JSON tree in a general case? No trivial at all.
    Shirley you can calculate and store some kind of hash over the JSON tree are compare that?



  • Order the keys by alpha order and hash the stringified version?



  • I suppose. But is hash comparison good enough for a DB? And how do you generate a hash that disregards unimportant differences in data structure?

    I'm far from expert in this, it's just what I saw when I dug through their forums a while ago.



  • Sanitize the unimportant differences (e.g, ordering)


  • 🚽 Regular

    @cartman82 said:

    I'm far from expert in this

    Was am I, but I hear good hashes can be made to make collisions extremely unlikely.

    In any case, I believe JSON structures are generally implemented as nested hashtables [citation needed] already, so you can just hash the hashes, dawg. (in a predefined order, probably alphanumerical)


  • :belt_onion:

    @Keith said:

    People running PHP on a Windows server. I don't get the WAMP stack at all; if you've already gone to the expense of Windows licensing, use a proper software stack.

    I WAMPed once.
    Mainly because my old PC came with Windows, and Apache+PHP are free.... definitely not more expensive.


  • BINNED

    @chubertdev said:

    Anything with Oracle is bad. Simply because Oracle is bad itself.

    The Oracle Client thing on windows is a special kind of evil. Extra joke is that when using ODBC to connect to oracle you just have to install the right oracle turd and then use MS's default supplied ODBC drivers since they actually work and are stable. Forget about the Oracle drivers that come with the turd. They might appear to work at first glance just to give you even more shit behind your back.



  • Unholy alliances: Disney-themed Big Mac app for iPhone available at Wal-Mart.

    Be afraid. Be very afraid.



  • @cartman82 said:

    The advantage of JSON type is you can access the data inside

    ......................why aren't you storing that data in, uh, you know,

    #the database



  • You are. You're just storing a nested document instead of normalized relations. Like MongoDB.
    Can be useful in some cases.



  • @cartman82 said:

    Can be useful in some cases

    Which cases?



  • For example, if you need to store a nested object which structure can vary (let's say it can map to several different subclasses in your code). This would be hell to implement in relations, but super easy as some kind of complex document (xml or json) you store and retrieve as a single value.


  • Discourse touched me in a no-no place

    @cartman82 said:

    But is hash comparison good enough for a DB?

    When the underlying model is of an unordered map with string keys? Yes. Anyone relying on the exact order of keys will get a rude awakening when they encounter any of the sane clients out there (including JS, which is the one everyone has).

    If they really give a shit about ordering, they should use an array or stick to XML.



  • @dhromed said:

    ......................why aren't you storing that data in, uh, you know,

    the database

    Maybe you want to store what Twitter's API returns verbatim, so if something about it changes you can go back and re-parse previous records.

    And something about it changes like every two weeks, so believe me, you want to store the JSON.



  • @da_Doctah said:

    Unholy alliances: Disney-themed Big Mac app for iPhone available at Wal-Mart.

    Be afraid. Be very afraid.

    What does a Big Mac app do?
    Does it make Big Macs?
    Does it taste like Big Macs?
    Can you dunk it in the toilet?



  • Agreed.

    Whether this is a problem with the idea of fully normalizing data or just a shortcoming of current databases, I don't know.


Log in to reply