So, where did J.C. Penney go wrong? Well, while we admire their attempt to change, they attempted to destroy over a century’s worth of price conditioning consumers have been through with department stores and pricing in general. They weren’t completely off base, as consumers with more and more access to information (comparison shopping engines, consumer reports, etc.), are beginning to realize that the value of products is determined much differently than a sticker would suggest. Yet, assuming that most soccer moms (and dads) wouldn’t fall prey to the colorful print ads tucked within the comics section in the Sunday paper, overlooks how much the majority of consumers value “winning” the retail game. Simply, deflating the perceived value causes customers to value the actual product less.

Almost no one ever pays full price. In fact, studies show that people are much more inclined to pay $25 for an item valued at $50, than paying for the same item without a sale at $25. It’s all about the “price framing” of a product that creates a perceived value, which all leads to the excitement of getting a good deal

This is Fantatical's annual "Bundlefest" so in this case it's just timing. They'll do this once a year and we just so happened to have a bundle with them not too long ago. It's not something we typically do.

Apologies: it's hyperbole. The parent site has a bunch of "spend x to get one of y Steam games" deals, which is what I was referring to. it was not meant literally. Just an attempt to build common ground with the poster who was talking about gambling and fomo.I thought they were referencing the larger site, so I wanted to acknowledge that so I didn't come off as dismissive of their concerns.Which turned out to be entirely separate concerns! Obviating the reason for the comment in the first place.Anyway, sorry for the short novel. But that's the danger of pithy one-liners: assumed context for the poster can be entirely lost in translation.Thanks for coming to my public apology press release?

Anyway, sorry for the short novel. But that's the danger of pithy one-liners: assumed context for the poster can be entirely lost in translation.

Eh, that's just sales. Humans are dumb, panicky animals: just look at how J.C. Penny's "Fair and Square" initiative went.Short version: they went full-on no bullshit: no limited time sales, no fake prices discounted, things cost what they cost, no more FOMO, no waiting for deals.It tanked. Horribly.

Why do companies insist on making deals a gamble? Is it basically just to capture FOMO sales?Both rhetorical questions.Edit: I'm talking about how you can pay one price for a deal and then a couple months later it's even cheaper.

I went by the reviews and now i am seeing a pattern on STEAM where even good reviews are bought and paid for and not really player revews and that actuallly watching game play from google will be my best option in the future. AGAIN don;t trust bought and paid for reviews from STEAM....I just learned and realised this now

It is based on the idea that each validation is encapsulated by a simple, stateless predicate that receives some input and returns either true or false.

URI::MailTo::EMAIL_REGEXP

It will return the result as a Dry::Monads::Result object which can be either successful or failure.

To understand this helper, you should understand that every step invocation calls Output() for you behind the scenes. The following DSL use is identical to the one [above]. class Execute < Trailblazer::Activity::Railway step :find_provider, Output(Trailblazer::Activity::Left, :failure) => Track(:failure), Output(Trailblazer::Activity::Right, :success) => Track(:success)

In combination with [Track()], the :magnetic_to option allows for a neat way to spawn custom tracks outside of the conventional Railway or FastTrack schema.

  DefTrack do :paypal do
    step :charge_paypal
  end

  paypal_track = RailwayTrack do :paypal do
    step :charge_paypal
  end

The Subprocess macro will go through all outputs of the nested activity, query their semantics and search for tracks with the same semantic.

For branching out a separate path in an activity, use the Path() macro. It’s a convenient, simple way to declare alternative routes

step :decide_type, Output(Activity::Left, :credit_card) => Track(:with_credit_card)

# Create the track, which would automatically create an implicit End with the same id.
Track(:with_credit_card) do
    step :authorize
    step :charge
end

class Example::ValidationErrorTrack < Trailblazer::Activity::Railway
  step :validate_model, Output(:failure) => Track(:validation_error)
  step :save,           Output(:failure) => Track(:validation_error)

  # Can't use fail here or the magnetic_to won't work and  Track(:validation_error) won't work
  step :log_validation_error, magnetic_to: :validation_error,
    Output(:success) => End(:validation_error), 
    Output(:failure) => End(:validation_error) 
end

puts Trailblazer::Developer.render o
Reloading...

#<Start/:default>
 {Trailblazer::Activity::Right} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=validate_model>
#<Trailblazer::Activity::TaskBuilder::Task user_proc=validate_model>
 {Trailblazer::Activity::Left} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error>
 {Trailblazer::Activity::Right} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=save>
#<Trailblazer::Activity::TaskBuilder::Task user_proc=save>
 {Trailblazer::Activity::Left} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error>
 {Trailblazer::Activity::Right} => #<End/:success>
#<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error>
 {Trailblazer::Activity::Left} => #<End/:validation_error>
 {Trailblazer::Activity::Right} => #<End/:validation_error>
#<End/:success>

#<End/:validation_error>

#<End/:failure>

class Example::ValidationErrorTrack::VPathHelper1 < Trailblazer::Activity::Railway
   validation_error_path = Path(end_id: "End.validation_error", end_task: End(:validation_error)) do
    step :log_validation_error
  end
  step :validate_model, Output(:failure) => validation_error_path
  step :save,           Output(:failure) => validation_error_path
end

o=Example::ValidationErrorTrack::VPathHelper1; puts Trailblazer::Developer.render o
Reloading...

#<Start/:default>
 {Trailblazer::Activity::Right} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=validate_model>
#<Trailblazer::Activity::TaskBuilder::Task user_proc=validate_model>
 {Trailblazer::Activity::Left} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error>
 {Trailblazer::Activity::Right} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=save>
#<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error>
 {Trailblazer::Activity::Right} => #<End/:validation_error>
#<Trailblazer::Activity::TaskBuilder::Task user_proc=save>
 {Trailblazer::Activity::Left} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error>
 {Trailblazer::Activity::Right} => #<End/:success>
#<End/:success>

#<End/:validation_error>

#<End/:failure>

Subprocess will try to match the nested ends’ semantics to the tracks it knows. You may wire custom ends using Output.

A nested activity doesn’t have to have two ends, only.

class Charge < Trailblazer::Activity::Path # ... step :validate step :decide_type, Output(Activity::Left, :credit_card) => Path(end_id: "End.cc", end_task: End(:with_cc)) do step :authorize step :charge end step :direct_debit end

module Trailblazer
class Charge < Trailblazer::Activity::Path
  # ...
  step :validate
  step :decide_type, Output(Activity::Left, :credit_card) => Path(end_id: "End.cc", end_task: End(:with_cc)) do
    step :authorize
    step :charge
  end
  step :direct_debit
end
end

puts Trailblazer::Developer.render a

#<Start/:default>
 {Trailblazer::Activity::Right} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=validate>
#<Trailblazer::Activity::TaskBuilder::Task user_proc=validate>
 {Trailblazer::Activity::Right} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=decide_type>
#<Trailblazer::Activity::TaskBuilder::Task user_proc=decide_type>
 {Trailblazer::Activity::Right} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=direct_debit>
 {Trailblazer::Activity::Left} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=authorize>
#<Trailblazer::Activity::TaskBuilder::Task user_proc=authorize>
 {Trailblazer::Activity::Right} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=charge>
#<Trailblazer::Activity::TaskBuilder::Task user_proc=charge>
 {Trailblazer::Activity::Right} => #<End/:with_cc>
#<Trailblazer::Activity::TaskBuilder::Task user_proc=direct_debit>
 {Trailblazer::Activity::Right} => #<End/:success>
#<End/:success>

step :direct_debit

Using Track() with a new track semantic only makes sense when using the [:magnetic_to option] on other tasks.

Defaults names are given to steps without the :id options, but these might be awkward sometimes.

step :default_name

step Subprocess(DeleteAssets), id: :delete_assets

Patching has no implicit, magical side-effects and is strongly encouraged to customize flows for a specific case in a quick and consise way.

However, it can be a PITA if you want to customize one of those deeply nested components and add or remove a certain step, for example.

In order to customize the latter one and add another step tidy_storage, you’d normally have to subclass all three activities and override steps.

step :policy, before: :create_model

the validate task gets removed, assuming the Admin won’t need a validation

magnetic_to: :paypal

step Subprocess(Memo::Validate), Output(:invalid_params) => Track(:failure)

While you could nest an activity into another manually, the Subprocess macro will come in handy.

The macro automatically wires all of Validate’s ends to the known counter-part tracks.

Output() in combination with Path() allow very simple modelling for alternive routes.

Note that the path ends in its very own end, signalizing a new end state, or outcome. The end’s semantic is :with_cc.

Since notify sits on the “failure” track and hence is “magnetic to” :failure, find_provider will be connected to it.

The Track() function will snap the output to the next task that is “magnetic to” the track’s semantic.

This connects the failure output to the previous task, which might create an infinity loop and waste your computing time - it is solely here for demonstrational purposes.

step :charge_creditcard, Output(:failure) => End(:declined)

Adding ends to an activity is a beautiful way to communicate more than two outcomes to the outer world without having to use a state field in the ctx. It also allows wiring those outcomes to different tracks in the container activity.

step :charge_creditcard, Output(:failure) => End(:success) end This reconnects both outputs to the same end, always ending in a - desirable, yet unrealistic - successful state.

step :find_provider, Output(UsePaypal, :paypal) => Track(:paypal)

The DSL will, per default, wrap every task with the Binary interface, meaning returning true will result in Activity::Right, and false in Activity::Left.

Currently, only Right signals are wired up.

Activity::Left

Note that you can return either a boolean value or a [signal subclass] in order to dictate the direction of flow.

allowing you to limit what invoked tasks or nested activies “see” and what they propagate to the caller context.

Please note that the actual task doesn’t have to be a proc! Use a class, constant, object, as long as it exposes a #call method it will flow.

You may use keyword arguments in your filters for type safety and better readable code.

In both filters, you’re able to rename and coerce variables. This gives you a bit more control than the simpler DSL.

Trailblazer will automatically create a new Context object around your custom input hash. You can write to that without interferring with the original context.

a method that doesn’t have access to variables outside its scope

As usual, you may provide your own code for dynamic filtering or renaming.

Please note that I/O works for both “simple” tasks as well as nested activities.

An array value such as [:params] passed to :input will result in the configured task only “seeing” the provided list of variables. All other values are not available, mimicking a whitelist.

Since we're not passing any inputs to ListAccounts, it makes sense to use .run! instead of .run. If it failed, that would mean we probably messed up writing the interaction.

You’re free to test this activity in a separate unit test.

# Yes, you can use lambdas as steps, too! step ->(ctx, params:, **) { params.is_a?(Hash) }

User.init!(User.new("apotonick@gmail.com"))

The fact we’re using ActiveRecord (or something looking like it) doesn’t mean Trailblazer only works with Rails! Most people are familiar with its API, so we chose to use “ActiveRecord” in this tutorial.

Keyword arguments allow to define particular parameters as required. Should the parameter be missing, they also provide a way to set a default value. This is all done with pure Ruby.

Yes, we could and should use Reform or Dry-validation here.

a task in an activity can be any callable Ruby object

Each step receives the return value of its predecessor. The return value decides about what next step is called.

In order to invoke, or run

the ability to “error out” when something goes wrong

Six lines of code create an executable object that, when invoked, will run your code in the order as visible in our diagram, plus the ability to “error out” when something goes wrong.

While you could program this little piece of logic and flow yourself using a bunch of Ruby methods along with a considerable amount of ifs and elses, and maybe elsif, if you’re feeling fancy, a Trailblazer activity provides you a simple API for creating such flow without having to write and maintain any control code. It is an abstraction.

keeps a semantic

A task is often called step.

Your actual logic happens in tasks, the labeled boxes. A task may be any callable Ruby object, an instance method or even another activity.

Every path or flow stops in a terminus event. Those are the filled circles. Often, we call them end event, too!

The “error path” or “failure track” is the lower path going the the failure terminus.

The “happy path” or “success track” is the straight path from start to the terminus named success.

Currently, only Right signals are wired up.

The sole purpose to add Dev::Trace::Inspector module is to make custom inspection possible and efficient while tracing. For example, ActiveRecord::Relation#inspect makes additional queries to fetch top 10 records and generate the output everytime. To avoid this, Inspector will not call inspect method when it finds such objects (deeply nested anywhere). Instead, it’ll call AR::Relation#to_sql to get plain SQL query which doesn’t make additional queries and is better to understand in tracing output.

Please note that this is a higher-level debugging tool that does not confront you with a 200-lines stack trace the way Ruby does it, but pinpoints the exceptional code and locates the problem on a task level. This is possible due to you structuring code into higher abstractions, tasks and activities.

They are an abstraction that will save code and bugs, and introduce strong conventions.

WE ARE CURRENTLY WORKING ON A UNIFIED API FOR ERRORS (FOR DRY AND REFORM).

At the request of the publisher, Tales of Monkey Island Complete Pack: Chapter 2 - The Siege of Spinner Cay is unlisted on the Steam store and will not appear in search.

I think one thing would have been a solution to basically everything here: Player created maps. As Im involved in many modding communities, I know for a fact that player created content can be vital in making games last so much longer, and the quality can shoot for the stars, Player created maps would have been fantastic for this game.

Licensed under the LGPLv3 license. We also offer a commercial-friendly license.

With Activity, modeling business processes turns out to be ridiculously simple: You define what should happen and when, and Trailblazer makes sure that it happens.

Version HEAD now

Tree Navigation

For that matter, why not remove the dependency on jQuery entirely (#111)?

Sure, zero-config one-click installs are nice and all, but:

Personally, I'm starting to think that the feature where it automatically adds xray.js to the document is more trouble than it's worth. I propose that we remove that automatic feature and just make it part of the install instructions that you need to add this line to your template/layout: <%= javascript_include_tag 'xray', nonce: true if Rails.env.development? %>

Now that I've thought more about it, I honestly think the auto-adding the script feature is overrated, over-complicated, and error-prone (#98, #100), and I propose we just remove it (#110).

now that I've thought more about it, I think the auto-adding the script feature is overrated, over-complicated, and error-prone (#100), and ought to just be removed (#110).

now that I realize how easy it is to just manually include this in my app: <%= javascript_include_tag 'xray', nonce: true if Rails.env.development? %> I regret even wasting my time getting it to automatically look for and add a nonce to the auto-injected xray.js script

Wasted too much time getting it to work with old Rubies/Rails, when I think the correct path should be to just remove support for them going forward

Open a separate PR to add Rails 6 to the CI matrix

I'm not very familiar with this feature. Do you know what version of Rails is required for this code to work? Is it Rails 6.0+? We run the test suite via Travis CI for many versions of Rails so I am concerned that this will cause test failures on older versions. Can we write the tests so that they gracefully exclude the CSP stuff on older versions where CSP is not supported?

(match = html.match(/<meta name="csp-nonce" content="([^"]*)"/)) && match[1] html[/<meta name="csp-nonce" content="([^"]*)"/, 1]

Non-blocking suggestion: This is a little more elegant, if you prefer this syntax:

This is failing CI because CI is testing against Rails < 6. I think the appropriate next steps are: Open a separate PR to add Rails 6 to the CI matrix Update this PR to only run CSP-related test code for Rails >= 6.0.0 Can you help with either or both of those?

Maintaining the builds of your repositories should be everyone’s job. Instead of relying on that one build person in the team, Travis CI makes infrastructure and configuration a team responsibility.

CI=true

Rebasing For feature/topic branches, you should always use the --rebase flag to git pull, or if you are usually handling many temporary "to be in a github pull request" branches, run the following to automate this: git config branch.autosetuprebase local

While I certainly don’t think that all configuration should be “self hosted” in this kind of way

That’s it. If you have a previous “precompile” array, in your app config, it will continue to work. For continuity sake I recommend moving over those declarations to your manifest.js file so that it will be consistent.

programmers can try to be aware of their configuration systems and the cognitive overhead they impose on people.

As we know, naming is hard.

Another thing I don’t like is the name of the config file manifest.js. Internally Sprockets has the concept of a manifest already Sprockets::Manifest, but the two aren’t directly coupled. We also already have a “manifest” JSON file that gets generated in public/assets/ and has manifest in the name .Sprockets-manifest-140998229eec5a9a5802b31d0ef6ed25.json. I know one is a JS file and one is a JSON file, but it’s a bit confusing to talk about.

The name makes me think of “The Legend of Zelda”. I imagine the original Sprockets author saying “It’s dangerous to go alone” and then handing me a javascript file.

The link name is not very helpful, it doesn’t explain what it does very well.

Instead of having this confusing maze of lambdas, regexes, and strings, we could, in theory, introduce a single entry point of configuration for Sprockets to use, and in that file declare all assets we wanted to compile. Well, that’s exactly what the manifest.js file is.

I guess in short you could say that I don’t like this interface very much.

Another big issue is that the config wasn’t really expressive enough. From the beginning Rails needed a way to say “only compile application.css and application.js, but compile ALL images” by default. With our previous interface, we’re limited to only strings.

That’s pretty gnarly. While the name of the constant LOOSE_APP_ASSETS gives me some idea of what it does, it still takes a second to wrap your mind around. If you were trying to figure out what assets are being precompiled and you did a puts config.assets.precompile that lambda object would be utterly baffling.

Another thing I don’t like: our asset behavior is decoupled from the assets. If you’re mucking around in your app/assets folder, then you have to first know that such a config exists, and then hunt it down in a totally different config folder. It would be nice if, while we’re working in asset land, we didn’t have to mentally jump around.

For example, what if your site has a customer interface and an “admin” interface? If the two have totally different designs and features, then it might be considerable overhead to ship the entirety of the admin interface to every customer on the regular site.

Before we get into what the manifest.js does, let’s look at what it is replacing.

When Sprockets was introduced, one of the opinions that it held strongly, is that assets such as CSS and JS should be bundled together and served in one file.

The alternative was to have multiple scripts or stylesheet links on one page, which would trigger multiple HTTP requests. Multiple requests mean multiple connection handshakes for each link “hey, I want some data”, “okay, I have the data”, “alright I heard that you have the data, give it to me” (SYN, ACK, SYNACK). Even once the connection is created there is a feature of TCP called TCP slow start that will throttle the speed of the data being sent at the beginning of a request to a slower speed than the end of the request. All of this means transferring one large request is faster than transferring the same data split up into several smaller requests.

One way to alleviate this configuration fatigue is by making configuration consistent and composable. That’s what Sprocket’s new “manifest.js” seeks to do.

Have you ever felt like a framework was getting in the way instead of helping you go faster? Maybe you’re stuck on some simple task that would be easy to do manually, but your framework is making you jump through configuration hoops. I end up getting lost in a sea of documentation (or no documentation), and the search for that one magical config key takes just a tad bit too long. It’s a productivity sink, and worse than the time delay it adds to my frustration throughout the day.

When I hit ETOOMUCHFRUSTRATION, then I’m definitely fighting the framework.

Local variables can even be declared with the same name as a global variable. If this happens, there are actually two different variables with the same name: one local and one global. This helps ensure that an author writing a local variable doesn’t accidentally change the value of a global variable they aren’t even aware of.

Sass variables, like all Sass identifiers, treat hyphens and underscores as identical. This means that $font-size and $font_size both refer to the same variable. This is a historical holdover from the very early days of Sass, when it only allowed underscores in identifier names. Once Sass added support for hyphens to match CSS’s syntax, the two were made equivalent to make migration easier.

echo "firefox hold" | sudo dpkg --set-selections

A build matrix is made up by several multiple jobs that run in parallel.

As a workaround, I guess I'll have to disable my strict CSP in development, but I'd prefer to keep it strict in development as well so that I ran into any CSP issues sooner...

At work, we often mention "throwing something over the fence" and "wrong rock" so there is (to us) a proverbial fence and a proverbial wrong rock.

Those things are someone else’s job, not ours, you know. 

Ruby on Rails 6 Note:: With the release of Rails 6 there have been some minor changes made to the default configuration for The Asset Pipeline. In specific, by default Sprockets no longer processes JavaScript and instead Webpack is set as the default. The twbs/bootstrap-rubygem is for use with Sprockets not Webpack.

Eyeglass provides a way to distribute Sass files and their associated assets and javascript extensions via npm such that any build system can be adapted to automatically expose those Sass files to Sass's @import directive by just installing the code.

This project is provided by the LinkedIn Presentation Infrastructure team as open source software

Keeping bootstrap-sass in sync with upstream changes from Bootstrap used to be an error prone and time consuming manual process. With Bootstrap 3 we have introduced a converter that automates this.

Do not use *= require in Sass or your other stylesheets will not be able to access the Bootstrap mixins or variables.

It's recommended to configure this library by setting environment variables.

STATSD_SAMPLE_RATE: (default: 1.0)

ENV['STATSD_SAMPLE_RATE'] = 1
config/initializers/statsd.rb:8:in `[]=': no implicit conversion of Integer into String (TypeError)

This version makes the new client that was added in version 2.6+ the default client, and removes the legacy client. All previously deprecated functionality has been removed (since version 2.5, see below).

Keep in mind that third party code with references to other files also processed by the asset Pipeline (images, stylesheets, etc.), will need to be rewritten to use helpers like asset_path.

vendor/assets is for assets that are owned by outside entities, such as code for JavaScript plugins and CSS frameworks.

How Sprockets works

Some assets will be compiled as top-level assets when they are referenced from inside of another asset. For example, the asset_url erb helper will automatically link assets:

but if you were previously using regexp or proc values, they won't work at all with Sprockets 4, and if you try you'll get an exception raised that looks like NoMethodError: undefined method 'start_with?'

To correct this, you can move these files to some subdirectory of ./app/assets/stylesheets or javascripts; or you can change the manifest.js to be more like how Rails with Sprockets 3 works, linking only the specific application files as top-level targets

When compiling assets with Sprockets, Sprockets needs to decide which top-level targets to compile, usually application.css, application.js, and images.

Here's the last issue where source maps were discussed before the beta release.

How do you know if source maps are working correctly? Try adding a syntax error to one of your assets and use the console to debug. Does it show the correct file and source location? Or does it reference the top level application.js file?

Source maps eliminate the need to serve these separate files. Instead, a special source map file can be read by the browser to help it understand how to unpack your assets. It "maps" the current, modified asset to its "source" so you can view the source when debugging. This way you can serve assets in development in the exact same way as in production.

Source maps are a major new feature.

Your Rails app Gemfile may have a line requiring sass-rails 5.0: gem 'sass-rails', '~> 5.0' # or gem 'sass-rails', '~> 5' These will prevent upgrade to sprockets 4, if you'd like to upgrade to sprockets 4 change to: gem 'sass-rails', '>= 5'

Sprockets 3 was a compatibility release to bridge Sprockets 4, and many deprecated things have been removed in version 4.

every human has a defined cognitive load that the memory can process. Making anyone process more information than defined will result in cognitive overloading.

Please be aware travis-ci.org will be shutting down in several weeks, with all accounts migrating to travis-ci.com.

Testing your open source projects will always be free! Seriously. Always. We like to think of it as our way of giving back to a community that connects so many people.

TravisCI.org is dead.

So, whenever you hear the medieval argument “Trailblazer is just a nasty DSL!”, forgive your opponent, you now know better. The entire framework is based on small, clean Ruby structures that can be executed programmatically.

The entire framework is based on small, clean Ruby structures that can be executed programmatically.

Redmond suggests nuking 'profanity, geopolitical, diversity' terms from browser source

Allowlist, not whitelist. Blocklist, not blacklist. Goodbye, wtf. Microsoft scans Chromium code, lops off offensive words

a proposal to cleanse the open-source code of "potentially offensive terms."

a suggestion by Microsoft to “cleanup of potentially offensive terms in codebase” aims to rid the software blueprints of language such as whitelist (change to allowlist), blacklist (change to blocklist), “offensive terms using ‘wtf’ as protocol messages,” and other infelicities.

In May, Microsoft announced AI features in Word that, among other features, will emit “advice on more concise and inclusive language such as ‘police officer’ instead of ‘policeman.’"

Good intentions, but I doubt there's any relation of the origin of the terms blacklist/whitelist to race. There are many idioms and phrases in the English language that make use of colours without any racial backstories. I haven't met any black person (myself included) who was ever offended by the use of "blacklist".

Regardless of origin, allow/deny are simply clearer terms that does not require tracing the history of black/white as representations of that meaning. We can simply use the meaning directly.

Frankly, a good number find it patronising to make this kind of change.

in functional programming, the terms "conditional expression" or "conditional construct" are preferred, because these terms all have distinct meanings

The forms of the final keyword vary:

found that using only the Pascal-provided control structures, the correct solution was given by only 20% of the subjects, while no subject wrote incorrect code for this problem if allowed to write a return from the middle of a loop.

What Böhm and Jacopini's article showed was that all programs could be goto-free.

That such minimalism is possible does not mean that it is necessarily desirable

computers theoretically need only one machine instruction (subtract one number from another and branch if the result is negative)

Literally, everything in this example can go wrong. Here’s an incomplete list of all possible errors that might occur: Your network might be down, so request won’t happen at all The server might be down The server might be too busy and you will face a timeout The server might require an authentication API endpoint might not exist The user might not exist You might not have enough permissions to view it The server might fail with an internal error while processing your request The server might return an invalid or corrupted response The server might return invalid json, so the parsing will fail And the list goes on and on! There are so maybe potential problems with these three lines of code, that it is easier to say that it only accidentally works. And normally it fails with the exception.

Return None. That’s evil too! You either will end up with if something is not None: on almost every line and global pollution of your logic by type-checking conditionals, or will suffer from TypeError every day. Not a pleasant choice.

Let’s start with the same number dividing example, which returns 0 when the error happens. Maybe instead we can indicate that the result was not successful without any explicit numerical value?

And we can specify types of wrapped values in a function return annotation, for example Result[float, ZeroDivisionError] returns either Success[float] or Failure[ZeroDivisionError].

Now you can easily spot them! The rule is: if you see a Result it means that this function can throw an exception. And you even know its type in advance.

we also wrap them in Failure to solve the second problem: spotting potential exceptions is hard

exceptions are not exceptional, they represent expectable problems

You can use container values, that wraps actual success or error value into a thin wrapper with utility methods to work with this value. That’s exactly why we have created @dry-python/returns project. So you can make your functions return something meaningful, typed, and safe.

Write special-case classes. For example, you will have User base class with multiple error-subclasses like UserNotFound(User) and MissingUser(User). It might be used for some specific situations, like AnonymousUser in django, but it is not possible to wrap all your possible errors in special-case classes. It will require too much work from a developer. And over-complicate your domain model.

Exceptions are not exceptional

Exceptions are just like notorious goto statements that torn the fabric of our programs.

(when used thoughtlessly)

Or you can use Maybe container! It consists of Some and Nothing types, representing existing state and empty (instead of None) state respectively.

So, what can we do to check for None in our programs? You can use builtin Optional type and write a lot of if some is not None: conditions. But, having null checks here and there makes your code unreadable.

But now, you can do the same thing in functional style!

Our mission is to allow people to make money via educational efforts and to dedicate the rest of their time to creating great open source products.

Examples

despite initially appearing to be an appropriate and effective response to a problem, has more bad consequences than good ones