1. 8

    As much as I’d love to see people actually pay for tools, I don’t quite get why they’re trying this with the JDK.

    1. 25

      Because people will fall into the trap, and they will get a call from Oracle’s compliance department, and Oracle will make money, and that will buy enough fuel to power the Larry Ellison for another day or so.

      1. 10

        Wanted to mention the following comment on the same note:

        https://palisadecompliance.com/oracle-org-chart/

        Granted the article is opionated and a bit dated (2013) but this shows what Oracle is capable of.

        1. 5

          I don’t know if it’s deliberate or by accident, but I like the idea of fueling a Larry Ellison.

          But it will be a drag to ensure proper compliance with these new rules…

          1. 30

            “…You need to think of Larry Ellison the way you think of a lawnmower. You don’t anthropomorphize your lawnmower, the lawnmower just mows the lawn, you stick your hand in there and it’ll chop it off, the end. You don’t think ‘oh, the lawnmower hates me’ – lawnmower doesn’t give a shit about you, lawnmower can’t hate you. Don’t anthropomorphize the lawnmower. Don’t fall into that trap about Oracle.” – Bryan Cantrill

            https://www.youtube.com/watch?v=-zRN7XLCRhc

      1. 3

        This seems to be a trend with major browsers recently — I definitely take issue with it, but I’m guessing there’s some rationale behind the decisions.

        1. 9

          Because URLs are hard to understand, apparently: https://www.wired.com/story/google-wants-to-kill-the-url/

          1. 7

            I don’t think URLs are working as a good way to convey site identity

            That’s because they are supposed to convey a location, not an identity.

            But it’s important we do something, because everyone is unsatisfied by URLs

            Who’s “everyone”? Never heard anybody say they were unsatisfied with URLs. Typical google-speak where they claim they are working for the greater good, while they are simply trying to twist the web to make it easier for their algorithms to process.

            1. 7

              That’s because they are supposed to convey a location, not an identity.

              A URL is a URI, so they are definitely also identifiers.

              1. 6

                Who’s “everyone”?

                I’m pretty sure the numbers speak loud enough about people not understanding URLs or its shortcoming only with all the successful phishing going around and all the confusion about the meaning of the padlock (Could be argued this is not an URL issue, but IMO still relies on the user understanding what is a domain).

                Domain and URLs should be abstracted away to the average user. The user wants to go on Facebook or Google, not https://facebook.com or https://google.com.

            2. 5

              I prefer what a lot of browsers do where they gray out most of the URL and show the domain name in full white/black

            1. 4

              Working on PWAifying some toy apps I’ve made. Knocked out https://unicode.pizza/ this weekend, now on to https://www.gliffic.com/.

              1. 5

                Detail work on my personal site, namely working on weird viewport size reckoning / scrolling behavior on mobile browsers. Also considering dropping in ServiceWorker caching and friends for offline access / buzzword practice.

                1. 4

                  Just a heads up: it scrolls really weird on iOS. I suppose it might be because of your implementation of the “sticky” header? I can’t look at the code right now, but I’d recommend either making the header sticky using position: sticky; top: 0, if that is the problem, or using -webkit-overflow-scrolling: touch, which would make it scroll more naturally in its current state.

                  1. 2

                    Thanks—I was avoiding position: sticky on purpose, but -webkit-overflow-scrolling:touch looks promising.

                    Update: That fixes scrolling, but breaks sub‐header re‐expansion when scrolled to the top. iOS sure is a treat to develop for when you don’t own a Mac.

                    1. 2

                      It feels a lot better now! Another problem, however, is that Safari’s bottom bar obscures the bottom of the page – for example, the submit button on the contact form. If you wait a second at the bottom and try to scroll again, you can reveal it, but it feels a little wonky. If you don’t want to redo the scrolling mehanism, a simple solution might be to just add a small margin at the bottom?

                1. 4

                  For fun, I’ve been building a web interface for Funhaus’ Google Trends Show, and as usual I’m being massively inconvenienced by CORS. This week’s contribution will probably be a server‐side component to sidestep it.

                  1. 4

                    Is this a feature people actually want? I work remotely and can say it’s not that useful to share an IDE session, but full-screen sharing (especially with voice chat) is a lifesaver. At least once a week we share our screens to flip between a browser window, a terminal, AND the IDE to demo something or replicate a bug.

                    I think it’s ironic that in the video they start off in Slack and share a link that you have to paste into VS. Slack itself has voice+video chat with screen sharing+control built in so there was no need to leave the app.

                    1. 6

                      Is this a feature people actually want?

                      YES. I work 100% remotely, and a lot of my work is mentoring newer developers by pair programming thorny problems with them. Screensharing is kind of okay at this, but sometimes saying, “On line 39, you need a closing paren. No, not there, back 6 characters. No. 6 characters.” is a little too challenging.

                      Slack itself has voice+video chat with screen sharing+control built in so there was no need to leave the app.

                      I’ve used ScreenHero in the past (the product Slack bought to power their system). In some ways it was better than screensharing. In other ways worse. I work on a Windows computer while most of my coworkers are on Macs. Even if we use the same editor, I’d have to use the Mac keyboard shortcuts in order to do anything useful.

                      If I understand this correctly, the Live Share feature allows you to use all your local shortcuts, etc. and just transmits the effect over to the other user’s editor. The difference between remotely using someone else’s editor, and having my local editor transmit changes over to them is HUGE.

                      1. 4

                        Is this a feature people actually want?

                        That’s a good question. This has never been on my list of wants.

                        It’s kinda cool that both developers get to use their own key bindings.

                        Maybe if you were pair programming, and you had two developers next to each other with their own keyboard/mouse/monitor, then having your own keybindings would be great.

                        – jorge.

                        1. 2

                          It’s something that I’ve been wanting since I used it in Eclipse a while back. It’s not really useful for professional collaboration, but it’s excellent for one‐on‐one teaching—no switching between windows or awkward vocal instructions. Also, it tends to be easy on bandwidth and avoid the sort of video artifacts that screen sharing brings.

                          1. 1

                            There’s a group of computational linguists at the University of Tromsø who swear by Subethaedit. They make everyone get Mac’s so they can run that. I’m guessing it has to do with constantly onboarding new phd students, getting them quickly set up in their dev environment, as well as collaborative article writing (though https://www.overleaf.com/ is now a better alternative for that). They’re always annoyed at having to use less capable editors like Etherpad with non-mac-users …

                            See also: https://www.reddit.com/r/emacs/comments/7d6hv0/real_time_collaboration_in_emacs/

                            1. 1

                              I use tmate whenever I need to remote pair; it lets you share both the editor and the terminal (of course; really I’m just sharing Emacs with terminal buffers inside it, but anyway) and it shows the exact same thing to both participants, whereas most buffer-centric sharing solutions I’ve seen had you enable sharing on a per-buffer basis, so you had to talk thru “OK, now I’m switching to this other file” over voice whenever you changed focus.

                              The slack-style screen sharing isn’t nearly as nice for my purposes because it’s read-only, whereas with tmate the other person can make edits easily.

                                1. 4

                                  That’s my reading, here- this is much-ado about the standard sort of text for any file hosting service. “Look, we’re going to need to make copies of your stuff, and sometimes when we show it, we’re only going to show parts of it, so, y'know, just FYI. Don’t come yelling at us if this somehow violates a license, blame whoever put the code here.”

                                1. 2

                                  I’d like to see some benchmarks between .NET, PHP7, and HHVM now that Peachpie seems to able to run real PHP applications.

                                  1. 2

                                    They do have some benchmarks against PHP 7, although it unfortunately doesn’t have HHVM, which is really what they’re up against.

                                    1. 1

                                      This is fantastic! I was thinking specifically WordPress benchmarks though. Maybe I’ll get around to setting up Peachpie myself and doing some tests.