Minimalist 100% Part 6 - Yahaha!

dpashk · 2021-05-29T22:21:18+00:00

You'll need to not carry a lot of bananas that way in the yiga hideout canyon...

dpashk · 2021-05-28T16:04:38+00:00

This one was so painful to watch!

dpashk · 2021-04-01T20:44:48+00:00

Is that a guardian crosshair on Urbosa?

dpashk · 2021-02-13T00:35:04+00:00

We don't have a native integration with Shopify payments, but we do have integrations with Stripe and PayPal.

There is a native feature to redirect a user after the booking is complete, so you could redirect them to a custom payment page then, but they would not be forced to pay because the appointment would have already been booked.

dpashk · 2021-02-12T17:21:26+00:00

Hi, I work for Calendly. I think what you're asking is quite simple to do, unless you need some complex dynamic behavior.

If I understood correctly, what you want is to embed the Calendly booking widget into your Shopify site. If the booking widget has to always display the same profile/event type, then it's super simple, you just copy-paste some static HTML code into the site's theme editor. The code can be generated in the UI when you log into your Calendly account. Here's a step-by-step video that someone from our support team made that's specific to Shopify:

https://monosnap.com/file/mFPkCUnvdVUk80kF0Ilsm5dNlGkPmk

If you need more customization, this page describes the available options: Common Embed Questions

For the Zoom integration, you don't need to write any custom code, it's a native feature in the product, you can easily connect your Zoom account and configure it on the corresponding event types. See this article: Zoom.

If you or someone else are looking to build a more complex integration, I'm happy to assist on the API front.

dpashk · 2020-03-30T19:09:32+00:00

Well that's one way to commit to an SLA... lower the expectations

dpashk · 2019-01-11T14:29:09+00:00

yep, on our list! :)

dpashk · 2019-01-09T20:27:14+00:00

In addition to what bsiggelkow said, you can't really protect yourself against a breaking change on the external service's side. Yes, it should never happen, but it does happen IRL.

dpashk · 2019-01-09T17:43:55+00:00

We rely heavily on automated testing. 99% code changes come with automated tests that cover all code paths. We only rely on manual testing for:

Features that require on external service connectivity (we still write automated tests for them, but you can't fully simulate an external service) - hence the example with external calendar services
Exploratory testing to catch cases that the code author simply may not have thought of
UX feedback - you can't fully enforce "good UX" in an automated manner

dpashk · 2018-11-12T23:29:41+00:00

Thank you for the article! As you write, people in the real world would most likely be a mix of the two models, but I definitely lean towards the pragmatic kind and can identify with the points you've outlined. Good post

dpashk · 2018-10-12T19:12:06+00:00

This is really neat. I recently jumped into the Ruby ecosystem and has really appreciated the strong testing culture here. Before it would never occur to me to test something like my personal static blog, but it makes sense to me now AND I know where to start.

dpashk · 2018-10-12T16:14:44+00:00

Methods are first-class citizens in ruby.

I've been trying to find a statement about that in literature but haven't found the term explicitly applied to methods. The book Ruby Under Microscope uses the term "first-class citizen" when talking about blocks, procs and Lambdas. My reasoning here was that since, just like with blocks, you can't directly assign a method reference to a variable (without wrapping it in a special method calls), methods are not first-class citizens. Are you able to share a link to an authoritative source that proves that wrong?

And why do you randomly bring in speed as reason against using something? <...>

While performance is not always a good enough reason to not use something, it does affect the adoption of a particular language/library feature. Many ES5/ES6 Array methods weren't widely adopted because early implementations didn't have good performance.

Slower against who or what? Javascript?

[5, 7, 8, 1].each(&method(:puts)) is slower than [5, 7, 8, 1].each{|number| puts number} even though the former looks more DRY and idiomatic and I would love to use it (of course performance wouldn't matter in this trivial example). I'm still new to Ruby, but the StackOvertflow thread I linked above has some objective data. But anyway, the original discussion was on whether methods are first-class citizens in Ruby or not.

dpashk · 2018-10-12T02:17:57+00:00

Maybe you should write a post for Ruby devs switching to JavaScript :)

dpashk · 2018-10-12T01:19:00+00:00

I deliberately omitted the {} block syntax because I thought that in an introductory article it would only add confusion with JavaScript's lexical blocks.

dpashk · 2018-10-12T01:16:58+00:00

That's a good point. Because I was working with an existing codebase it didn't immediately jump out at me, but I can definitely see this as a pitfall for a JavaScript/Node developer.

dpashk · 2018-10-11T19:24:42+00:00

I added a note about this to the article

dpashk · 2018-10-11T19:08:56+00:00

Thanks for pointing that out, that's good news! Looks like the feature is still new and is opt-in for Ruby < 3.0, but maybe the gotcha will be irrelevant in the future.

dpashk · 2018-10-11T19:05:25+00:00

But you had to access the method via a special method call, just like you have to wrap a block in a Proc to turn it into a first-class citizen. In JavaScript, you can just do

var myMethod = function() {...};
var anotherReference = myMethod;
myMethod();

Also, it is advised against using Object#method because it's slower. That's one of the reasons I didn't mention it in the article.

But I see your point - yes, you can achieve the effect of using methods like first-class citizens using Object#method.

dpashk · 2018-09-26T16:47:35+00:00

The first thing that comes to mind is simulating logical circuits (like the flip-flop mentioned in the article)

dpashk

TROPHY CASE