• (disco) in reply to sloosecannon

    Actually, I think what's at fault there is duck-typing.

    If I check for false, it better be false for that check to pass, goddamit

  • (disco) in reply to sloosecannon

    The awesome thing is that it uses the same method to communicate errors about JSON parsing.

    Even though "false" is a perfectly valid JSON value.

  • (disco) in reply to blakeyrat

    Yeah, that's just... beyond words stupidity.

  • (disco) in reply to Onyx
    Onyx:
    I'm actually torn on whether I like it in some cases or not.

    For example, strpos returns 0 if substring is found at the beginning of the string, FALSE if substring is not found. C would return -1 in place of FALSE.

    Other programming languages have better ways of handling this. In Haskell, you would have the strpos equivalent return a Maybe Int, which would have a value of Just n where n is the index where the substring is found or Nothing if the substring is not found. Maybe Int and Int are two different types, so the compiler wouldn't let you use one where the other is expected, and converting would give a warning if you didn't handle both cases.

  • (disco) in reply to sloosecannon
    sloosecannon:
    How to print computer program using PHP?

    Use jQuery! Hanzo does!

  • (disco) in reply to blakeyrat
    blakeyrat:
    Even though "false" is a perfectly valid JSON value.

    Well... only kind of:

    Note: PHP implements a superset of JSON as specified in the original » RFC 4627 - it will also encode and decode scalar types and NULL. RFC 4627 only supports these values when they are nested inside an array or an object. Although this superset is consistent with the expanded definition of "JSON text" in the newer » RFC 7159 (which aims to supersede RFC 4627) and » ECMA-404, this may cause interoperability issues with older JSON parsers that adhere strictly to RFC 4627 when encoding a single scalar value.

    php > var_dump(json_decode(false));
    NULL
    php > var_dump(json_decode(3));
    int(3)
    php > var_dump(json_decode("string"));
    NULL
    php > var_dump(json_decode("false"));
    bool(false)
    php > var_dump(json_decode(""));
    NULL
    
    php > var_dump(json_encode(3));
    string(1) "3"
    php > var_dump(json_encode(false));
    string(5) "false"
    php > var_dump(json_encode("string"));
    string(8) ""string""
    
    

    No, I have NFC why giving it "false" as a string is a failure. Edge case of some kind I guess, I didn't read the RFC TBQH.

    Backwards compatibility stuff on the decoding part for the rest. I never ran into this as considered valid in the wild though. Not that it's an excuse, but I do find it a bit odd to allow bare values without a proper object or an array. I'm kind of failing to see the a legitimate use, too. As in, why wouldn't you stick in into an array for example, rather than just sending, say, a bare interger as a response? Surely, 2 bytes of perceived overhead is nothing to worry about?

  • (disco) in reply to blakeyrat

    Could be a way of migrating the code to use a different naming convention. Years ago I had some code with loads of wrappers along the lines of emulate_randomname() { system_sensiblename(); } during the transition when imposing a consistent naming scheme on the code.

  • (disco) in reply to ben_lubar
    ben_lubar:
    I saw a job ad that wanted proficiency in the following four fields:

    PHP node.js MySQL MongoDB

    I'm not sure what they're making, but why the fuck do they need all four of those things?

    Maybe a merger, and they're trying to consolifrobnicate different databases.Or some tie-wearer has decided to switch from MySQL to MongoDB for raisins.

    sloosecannon:
    fallback servers

    Time to get new glasses. I read "failback servers" the first time.

  • (disco) in reply to PWolff
    PWolff:
    consolifrobnicate

    + :fa_book:

    PWolff:
    Or some tie-wearer has decided to switch from MySQL to MongoDB for raisins.

    MongoDB is web scale!

    PWolff:
    failback servers
    Given the situation described, it is an apt monicker
  • (disco) in reply to blakeyrat
    blakeyrat:
    TheCPUWizard:
    Because (for the types of sites I work with), the WebServer would be publically exposed and contact a set of services (likely, but not necessarily ReST) that reside in a more secure environment which would in turn (either directly or not) contact the DB.

    Why stop there?

    Better have that REST service call other REST services. Just in case. In fact, better add another layer or two. Make sure as much pointless, stupid code gets between the user and their data as possible.

    Challenge:

    Put as many hoops between a web user and the backend data as possible. Difficulty: Site servers on same LAN and no esoteric stuff, (IP over Avian, etc)

    Raid0 -> Distributed File System -> DB Server -> Windows DSN Entry -> RPC Service -> Web Server -> SOAP Service -> Rest Service -> JQuery -> data presented in Alert box from span onClick.

  • (disco) in reply to Nexzus

    Why not just

    SSD -> DigitalOcean droplet -> PostgreSQL -> Ruby -> V8 -> Rails -> Nginx -> Ember -> 503 OK -> 503 OK -> 503 OK -> 503 OK -> ... -> 503 OK -> web browser

  • (disco) in reply to Nexzus

    Don't forget to make sure the REST service isn't actually RESTful, completely negating the point ;)

  • (disco) in reply to Nexzus

    We are having some performance issues with our setup - could you take a look?

    RAID3 -> SAN -> Distributed Content-Addressable File System -> NoSQL Distributed Data Store -> cron-run PHP script -> JSON-RPC -> RabbitMQ -> Apache Spark Streaming Batch Processor -> Postgresql -> Redis Cluster (for caching) -> Business Logic Layer -> Service Layer -> WebSocket frame -> Flux Action Dispatcher -> Unread notification icon shows up by user's avatar.

  • (disco) in reply to Nexzus
    Nexzus:
    Raid0 -> Distributed File System -> DB Server -> Windows DSN Entry -> RPC Service -> Web Server -> SOAP Service -> Rest Service -> JQuery -> data presented in Alert box from span onClick.

    Things can go overboard, but there is no way I am going to ever put a corporate database on a machine that can be directly connected to the Internet.

  • (disco) in reply to svieira

    I would have liked it, but I ran out of energy by the time I moused over all the abbr tags.

  • (disco) in reply to Nexzus
    Nexzus:
    Difficulty: Site servers on same LAN and no esoteric stuff, (IP over Avian, etc)
    Bah. We ship our data offsite so that we don't have to worry so much about managing a big-ass tape store…

    I also note that you are not using a Business Process Management System.

  • (disco) in reply to TheCPUWizard
    TheCPUWizard:
    there is no way I am going to ever put a corporate database on a machine that can be directly connected to the Internet

    When I support clients, it's through Teamviewer installed on their servers.

  • (disco) in reply to Jaloopa
    Jaloopa:
    When I support clients, it's through Teamviewer installed on their servers.

    Look at the info published by Gartner. It is estimated that up to 15% of all data breaches (at the server level) result from external support access capabilities (not specifically TeamViewer)....

    Typical recommendation is at least a double hop.

  • (disco) in reply to izzion
    izzion:
    abbr tags.

    They show up on mobile

    [image]
  • (disco) in reply to Zemm

    No repro: [image]

  • (disco) in reply to Tsaukpaetra

    Maybe discourse doesn't believe that a full HD screen in portrait could possibly be mobile!

  • (disco) in reply to Zemm

    Hot diggity, you're right! [image]

    Though, now this tab is stuck in "micro mode"... [image]


    Filed under: Just keep refreshing, just keep refreshing, just keep refreshing refreshing, refreshing, what do we do we refresh....

  • (disco) in reply to Tsaukpaetra

    This view is actually cool, I can see that a pasted image is a pasted image!

  • (disco) in reply to Zemm
    Zemm:
    They show up on mobile

    That's a here-only hack I added to the mobile CSS:

    /* Make acronym behave like abbr */
    acronym[title] {
      border-bottom: 1px dotted;
    }
    acronym[title]:after {
       content: " [" attr(title) "]";
    }
    
    /* Show abbr and a title contents on mobile */
    abbr[title]:after
    {
       content: " [" attr(title) "]";
    }
    .cooked a[title]:after
    {
       content: " [" attr(title) "]";
    }
    
  • (disco) in reply to NedFodder
    NedFodder:
    Discourse!!!

    I was surprised it synchronises the click count on all the links pointing to the same place. Before I tried clicking just one of them I wondered if that was the case or previous 9 people clicked every one of them in an OCD fashion. Or maybe 36 people clicking different links to maintain the balance.

  • (disco) in reply to TheCPUWizard
    TheCPUWizard:
    blakeyrat:
    If your site's in PHP, PHP is your back-end. Why wouldn't you access the database with it?

    Because (for the types of sites I work with), the WebServer would be publically exposed and contact a set of services (likely, but not necessarily ReST) that reside in a more secure environment which would in turn (either directly or not) contact the DB.

    Makes for a MUCH better scalability server when you need to create a garden or farm for your front ends.

    Exactly

  • (disco) in reply to blakeyrat
    blakeyrat:
    Helix:
    I am not a web developer, but perhaps someone could tell me why you want to access a database with PHP directly?

    As opposed to...?

    If your site's in PHP, PHP is your back-end. Why wouldn't you access the database with it?

    I thought PHP was on the server site, but still it is on a server that is publicly exposed... so why would it be able to access the database server directly.

    Anyway, to answer your question, use BobX.

Leave a comment on “All Wrapped Up”

Log In or post as a guest

Replying to comment #:

« Return to Article