- Feb 2023
-
stackoverflow.com stackoverflow.com
-
Result of lots of searching on net is that pre-checkout hook in git is not implemented yet. The reason can be: There is no practical use. I do have a case It can be achieved by any other means. Please tell me how? Its too difficult to implement. I don't think this is a valid reason
-
- Apr 2021
-
github.com github.com
-
Actually, I've decided to stop using labels for a while. A "bug" label gives the impression that someone else is going to fix the problem. We don't have enough volunteers for that (new contributors welcome!). I try to help people working on issues, though. I've spent many hours on this one.
-
-
stackoverflow.com stackoverflow.com
-
If anything it thwarts separation of concerns to a degree.
-
-
-
Of course you must not use plain-text passwords and place them directly into scripts. You even must not use telnet protocol at all. And avoid ftp, too. I needn’t say why you should use ssh, instead, need I? And you also must not plug your fingers into 220 voltage AC-output. Telnet was chosen for examples as less harmless alternative, because it’s getting rare in real life, but it can show all basic functions of expect-like tools, even abilities to send passwords. BUT, you can use “Expect and Co” to do other things, I just show the direction.
Tags
Annotators
URL
-
-
unix.stackexchange.com unix.stackexchange.com
-
However you're probably asking the wrong question. (Not necessarily, for example this might come up in a makefile.)
-
- Mar 2021
-
trailblazer.to trailblazer.to
-
Hey, that’s is an imaginary complication of our example - please don’t do this with every condition you have in your app.
-
- Feb 2021
-
trailblazer.to trailblazer.to
-
For branching out a separate path in an activity, use the Path() macro. It’s a convenient, simple way to declare alternative routes
Seems like this would be a very common need: once you switch to a custom failure track, you want it to stay on that track until the end!!!
The problem is that in a Railway, everything automatically has 2 outputs. But we really only need one (which is exactly what Path gives us). And you end up fighting the defaults when there are the automatic 2 outputs, because you have to remember to explicitly/verbosely redirect all of those outputs or they may end up going somewhere you don't want them to go.
The default behavior of everything going to the next defined step is not helpful for doing that, and in fact is quite frustrating because you don't want unrelated steps to accidentally end up on one of the tasks in your custom failure track.
And you can't use
fail
for custom-track steps becase that breaksmagnetic_to
for some reason.I was finding myself very in need of something like this, and was about to write my own DSL, but then I discovered this. I still think it needs a better DSL than this, but at least they provided a way to do this. Much needed.
For this example, I might write something like this:
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
I guess that's not much different than theirs. Main improvement is it avoids ugly need to specify end_id/end_task.
But that wouldn't actually be enough either in this example, because you would actually want to have a failure track there and a path doesn't have one ... so it sounds like Subprocess and a new self-contained ProcessCreditCard Railway would be the best solution for this particular example... Subprocess is the ultimate in flexibility and gives us all the flexibility we need)
But what if you had a path that you needed to direct to from 2 different tasks' outputs?
Example: I came up with this, but it takes a lot of effort to keep my custom path/track hidden/"isolated" and prevent other tasks from automatically/implicitly going into those steps:
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>
Now attempt to do it with Path... Does the Path() have an ID we can reference? Or maybe we just keep a reference to the object and use it directly in 2 different places?
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>
It's just too bad that:
- there's not a Railway helper in case you want multiple outputs, though we could probably create one pretty easily using Path as our template
- we can't "inline" a separate Railway acitivity (Subprocess "nests" it rather than "inlines")
-
step :direct_debit
I don't think we would/should really want to make this the "success" (Right) path and :credit_card be the "failure" (Left) track.
Maybe it's okay to repurpose Left and Right for something other than failure/success ... but only if we can actually change the default semantic of those signals/outputs. Is that possible? Maybe there's a way to override or delete the default outputs?
Tags
- powerful
- feels wrong
- flexibility
- verbose / noisy / too much boilerplate
- I have a question about this
- example: in order to keep example concise/focused, may not implement all best practices (illustrates one thing only)
- helper functions
- tip
- concise
- useful
- example: not how you would actually do it (does something wrong/bad/nonideal illustrating but we should overlook it because that's not the one thing the example is trying to illustrate/show us)
- trailblazer-activity
- semantics
Annotators
URL
-
-
sobolevn.me sobolevn.me
-
we also wrap them in Failure to solve the second problem: spotting potential exceptions is hard
-
exceptions are not exceptional, they represent expectable problems
Tags
- exceptions are expectable, not exceptional
- difficult/hard problem
- key point
- exceptions that are not exceptional
- error/exception handling
- anticipating what could go wrong / error/exception cases
- error/exception handling: spotting potential exceptions is hard
- easy to miss / not notice (attention)
Annotators
URL
-
- Nov 2020
-
mywiki.wooledge.org mywiki.wooledge.org
-
Some people try to use && and || as a shortcut syntax for if ... then ... else ... fi, perhaps because they think they are being clever.
-
- Sep 2018
-
cnx.org cnx.org
-
City officials can actually help if they go out into the streets and ask real people what actually is going on. Something on blogs and on polls arent true, they dont always speak the truth. If they were to go out to communities and build relationships with people, they would have a clearer understanding of what is going on.
Tags
- https://hypothes.is/groups/q2jXEin4/f18-51-hybrid)
- group: F18-51-Hybrid
- City officials cannot fix problems if they do not know anything is wrong to begin with. Responding to public opinion polls, actively contributing to a political blog, or starting a new blog are all examples of different ways to be involved.
Annotators
URL
-
- Nov 2016
-
www.usatoday.com www.usatoday.com
-
Coral reefs result from the work of little polyps, creatures only a few millimeters long, budded on top of one another. Over centuries, the shells of these creatures combine to form the exotic shapes of coral reefs. Tiny differences in the anatomy of each polyp species affect the shape of their shells and produce the exotic shapes of each reef.
Skeletons, not shells. Far from the most articulate description but generally not wrong.
-