DCoder

I'm partial to Signpost and Towers.

Yes. I just wrote a Chrome extension this week, using plain ES6. There was not enough code in it to require TypeScript or Webpack.

I haven't tried Flow, so I can't say.

IntelliJ Ultimate user here, writing and refactoring TS works quite well. There are some minor issues (e.g. sometimes it doesn't show the usual "this method is overridden in a child class" indicator), and refactoring likes to randomly modify somearray['foo'] when renaming a someclass.foo property, but I can live with that.

A man is walking down the street carrying a 12-roll pack of toilet paper. People surround him, all excited: "Where'd you get that?" The man answers, "I just got it back from the dry cleaner's!"

(source: Viktor Suvorov's fascinating Kuzkina Mat [1])

[1]: http://andrewnurnberg.com/book/kuzkina-mat/

* Steven Levy – Crypto

* Stephen King – 11/22/63

* Michael R Underwood – Geekomancy series

11/22/63 in particular is hard to put down, King doesn't need the supernatural to create a thrilling story.

You can also look at https://github.com/scmbreeze/scm_breeze

The term for this is "Magpie-driven development".

> one reason is that basic auth lost out early on to site-supplied login forms, so people got used to entering usernames and passwords into the page content anyway, instead of the browser UI

To be fair, basic auth is not particularly user-friendly. If you want to add anything else to the login form, such as a "Remember Me" checkbox or a captcha, you can't put that in the browser chrome, you need to add an additional step in the login flow. If you want an "Did you forget your password? Click here to reset it." error message, the user has to cancel out of the auth dialog in frustration before they can see it (or you have to redirect them to an error page after failed auth, with another link/button to Try Logging In Again.

And even if you solve those problems, the user still needs to enter their username/password when creating their account, and I have never seen Basic Auth used for this scenario.

I thought so. What if I don't hate my job yet? Should I just give it more time? :)

BlueAcorn Universal Analytics.

> find an unrelated but expensive hobby

Why expensive?

I use the verbose version for readability:

    set -o errexit
    set -o nounset
    set -o pipefail

Some commands need custom error handling, which means turning off -e:

    set +o errexit

    ansible-playbook ...

    if [[ "$?" != "0" ]]; then
        echo -e "\e[1;31m""Error when executing ansible!""\e[0m"
        exit 1
    fi

    set -o errexit

And if you use -e , you will probably need the default value helper to validate input arguments:

    # the :- operator means "use the right side value if the left side ($1) is not set"
    env=${1:-}
    
    inventoryFile="${baseDir}/env/${env}/inventory"

    if [[ -f "${inventoryFile}" ]]; then
        echo -e "\e[1;31m""Invalid environment specified!""\e[0m"
        exit 1
    fi

Hex-Rays is a pretty good decompiler plugin for IDA Pro: https://www.hex-rays.com/products/decompiler/index.shtml

I have been working with Magento CE 1.x for several years now. I have spent at least a hundred hours inside the debugger carefully stepping through the seventy layers of its core code to make sense of it. I can list a lot of problems I have seen in it. However, I cannot recommend any alternatives: I refuse to touch WordPress because it's WordPress, I have no intention of using OpenCart because I have already tried it once and its author is a crazy man, and I have no experience with Shopify or Prestashop.

Business issues:

* Magento is in control of your price structure. You will structure your prices in the way that Magento allows, or you will suffer. Our client was not happy with the price calculation, so we spent hundreds of hours changing it thoroughly. Do you want tier prices for product options? Too bad. Do you want customer group prices for product options? Too bad. Do you want to set discount values as "discount this much after applying all taxes" (e.g. because your shop displays only prices after tax)? Too bad, all you can do is "discount this value on the untaxed price, plus whatever reduction that makes on taxes" or "calculate the discount amount off the taxed price, then discount that much off the untaxed price". And once you have made some price customizations, the customer will find an extension that does something to the prices and breaks your changes in a creative, subtle, and unexpected way.

* The CMS part of Community Edition is a joke without a punchline. It doesn't even have any menu module, only the ability to manage pages with content dumped in an RTE.

* Our clients were originally in love with Magento because "we can just add all these existing modules and get all sorts of awesome functionality without having to pay you for it!" We warned them that that was a pipe dream, but they didn't listen. Now they have several thousand hours worth of custom development on top of Magento 1.x (95% of it written solely by me, no bus factor problems with that) and they're still asking for more. Last I checked, the end-of-life for M1.x is planned in December 2018, and the client has no plan for what to do then.

Technical issues:

* The database API has an "you want it, you got it!" mentality - if you tell it to add a unique index and MySQL refuses to because existing data is not unique, the API will parse the MySQL error message to identify the duplicated fields/values and delete the duplicate rows silently. You will get your index, but you might no longer have all your data. [0]

* The model classes store nearly all the in-memory data in an untyped dictionary. You can call $model->setFoobar('12345') and later $model->getFoobar() to get it back - all unknown method calls get forwarded to a "catch-all" method which treats the method name as a key into this dictionary, and gets/sets a value of that key [1]. Most of the time, these calls are unannotated, so IDEs can't make any sense of them (see the "Undefined method" part in [2]). This magic is also a performance issue, so they make optimizations like [3] by inlining pieces of the catch-all handler code for commonly-used data.

* EAV models. In theory, a workable idea, and you can even make your own EAV models if needed. In practice, you need to spend a lot of time in the debugger stepping through the code to figure out what code in the Product or Customer classes needs to be copied into your custom EAV model to make it work right, because the core EAV model doesn't have half the needed functionality.

* Misleading code comments and annotations. Nothing like finding a method whose phpdoc says it returns a class that does not exist in the codebase.

* XML configuration jungle:

* Module configuration and theming configuration is based on heaps of XML that has no schema. Module configuration combines XML documents in the "there can be only one" manner (if two documents have XML nodes with the same path, the second one's value overwrites the first one), specifically so modules can change each other's configuration.

* Theming layer operates on "blocks", which are basically a PHP class with a corresponding .phtml template file. These blocks are defined, managed, and composed through XML files. You can even encode instructions like "after creating this block, call its method foo()" in the XML. If your theming doesn't seem to take effect, you get to step through the loader to figure it if it's not loading your file, if some file loaded later is giving different instructions, or if you placed your code in the wrong place in the XML structure. Or if there's some extra XML configuration in the database specifically for this category/product/CMS page. Happy hunting!

* Using third-party modules and themes is a russian roulette:

* Magento includes a "Developer Mode" where php notices and warnings are turned into exceptions like in sane languages. However, lots of modules and themes have never been tested with this setting on and they cause faults on every page load - either you have to disable the Developer Mode, or fix this third-party code.

* Some modules are well written, some do crazy things completely at odds with Magento workflow (e.g. an extension to set custom tier prices that calculates them when you load the product from the DB and ignores the precomputed price index in the DB), some are downright broken. And some of them contain gaping security holes – are you going to audit all the third-party code you include [4]?

* Magento core JavaScript is based on Prototype.js, not jQuery, so half the modules and themes bundle their own copies of jQuery and drop them in different locations. Some of them provide a configuration setting so you can disable their jQuery and use your own, some don't. I have seen a page that loaded Prototype, ExtJS, jQuery, and Angular side by side.

* As with every extendable system, some extensions don't work well together. Every module has the ability to override a Magento core class. Fun happens when two different modules want to override the same core class.

* Other

* Performance is demanding. You need powerful hardware and good caching to get good performance. And then you'll get that one extension that tanks your performance, like the Analytics plugin that loads each product in a category individually to send its data to Analytics when you view the category page.

* Security updates are fun. When you log into the admin panel, you will see a notification about a new security update. This notification shows up because a scheduled task periodically fetches a news feed, which contains security alerts, new version announcements, marketing spam, and whatever else Magento wants to show you. You read the notification, and follow a link to the Magento downloads page. There, after logging in, you can find and download a .sh file which contains both the patcher and the patch content itself. Run it to apply the patch. If the security issue is critical enough, Magento will publish a repeated reminder to apply it a few days later. Which your news feed will again pick up and dutifully display to you, despite the fact that you've already applied that patch. You will also get a panicked call from the client because he logged into the backend and saw that message too.

* Some things are just silly:

* Translation manager cannot cache the translations correctly, you get different translations for the same input with caching enabled and disabled.

* One class has both escapeUrl() and urlEncode() methods, and neither of them actually does URL encoding.

[0]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/...

[1]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/...

[2]: https://imgur.com/RMxWEgR

[3]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/...

[4]: https://news.ycombinator.com/item?id=13100162

Somewhat on topic: I work 4-days/10-hours: 2 morning hours from home, commute to the office clears my head, 8 hours in the office, and Friday is free.

Pros:

- three-day weekends all year long

- 20% less commute time

- magically enforces the "Read-only Friday" rule

- if I have to handle an emergency on Friday, it means overtime pay

- Friday is good for running errands

Cons:

- clients/coworkers still work on Fridays, so I can't ignore my email entirely

- occasional meetings happen on Friday

This is probably not a good schedule for everyone, but I have been working it for 2 years now and I like it a lot. Although none of my coworkers are following this example...

Using a VM is the reason to use Vagrant.

Isolation and reproduction.

For one thing, you want the development environment to be as similar to production as possible – same OS version, same webserver version, same DB version, same dependencies, no unwanted extras that differ between environments.

For another thing, you don't want to have to solve conflicts between project A and completely unrelated project T if you need to work on them both.

Generics are a pretty integral part of the type system, not a "Java feature". And TS has other good features besides types, e.g. transpiling to ES5, async/await, TSX, decorators. What does pure ES6 offer instead?

I am avoiding Angular entirely (I'm not a fan of the "and the kitchen sink" approach it promotes), so I can't comment if they're taking TS too far.

> getting things done quickly and easily

Sure, fast turnaround is good. Being able to maintain and refactor what you made a year later is even better. I'm currently refactoring an app that has ~30k sloc TypeScript, and doing it without types would be a lot worse.

However, my app is not built in Angular, so my experience here may be quite different.

> And it lets one write plain old ES6, a luxury in this age of TypeScript fascism by psychopathic ex-JBoss villains.

This opinion is one of the many things that are wrong with the JavaScript ecosystem today. Static typing as provided by TypeScript is a safety net, not "fascism".

PHPMailer can be configured to send mail through raw SMTP, by directly invoking sendmail, or by calling PHP's mail() function (which is a thin wrapper around sendmail). This vuln affects the last mode, where the command line is invoked by PHP itself. Yes, a good admin would configure mail differently, but this being PHP, it tries to be flexible and support the simplest options possible.

> When configured to use CLI sendmail,

That's not correct. PHPMailer can be configured to send mail through raw SMTP, by directly invoking sendmail, or by calling PHP's mail() function (which is itself a wrapper around sendmail). This vulnerability affects only the last mode, when PHP's mail() calls sendmail. If you have PHPMailer configured to call sendmail directly, this vulnerability does not apply.

The parent post said "only implementations using sendmail (ie. not mail() or SMTP) are affected".

From my reading of the code, "only implementations using mail() (ie. not sendmail or SMTP) are affected".

That's not correct, the added escapeshellarg() call is inside the mailSend() function, which sends mail through php's mail(). See [1].

[1]: https://github.com/PHPMailer/PHPMailer/blame/4835657cd639fbd...

That added call to escapeshellarg sanitizes the "From" address before passing it to PHP's mail() function as an additional parameter. That function will invoke a preconfigured executable (sendmail or a compatible wrapper) and pass that parameter to it along with the rest of the email data. It is worth noting that:

1) PHPMailer can be configured to send mail through raw SMTP, by directly invoking sendmail, or by calling PHP's mail() function. The changes in this commit only affect the last mode.

2) The "From" address is typically chosen by the site operator/server administrator, not customizable by a site visitor. I have built sites with "share this page with a friend" functionality that sent email from one given email address to another, but this practice seems to have fallen out of favour when SPF became popular.

Or, once they have learned the alien language, they see legitimate shortcomings in it that their native language doesn't have.

Web dev chiming in with a similar experience. Last month I interviewed three people claiming multiple years of PHP/MySQL experience, not one of them could tell me what an SQL transaction is.

Thank you for the contact details, I'll send you the details of the security issues later this week.

This extension was purchased through Magento Connect just a few months ago. I'm glad to hear the situation is improving now.

> utf8mb4 comes with some technical "gotchas" (google it)

I know InnoDB limits index sizes to 767 bytes, meaning VARCHAR(255) using utf8 can have all 255 characters indexed, but VARCHAR(255) using utf8mb4 can only index 191 characters (floor(767/4) == 191).

After a quick Google search, that seems to be the most common gotcha. What other gotchas did you have in mind?