I just accepted the suggestion and it randomly stops at some point and then I can continue this as long as I want.

Haha, it now shows this error icon and when I hover over it, it says "CoPilot is encountering temporary issues (click for details)" and if I click, nothing happens. I think, I might have broke sumfin.

I guess copilot isn't optimized for languages that are sufficiently expressive...

haha nice!

> besides looking at the HTTP requests The only thing besides the requests is what drives them. Usually it's user actions, sometimes it's other code (`setTimeout` or some other non-user communication).

Built in browser Dev tools give a pretty good picture (A) network tab shows reqs/response (B) script tab can show pretty printed code and let you add break points (C) Inspect tab lets you see the DOM after manipulation by Javascript (D) application tab lets you see what's in cookies and local storage. When doing an unoffial API - I expect a programmer to be spending a long time looking at how it works (often this takes more time than the coding part).

> (B) script tab can show pretty printed code and let you add break points > How would you go about looking for somewhere to put breakpoints in almost-certainly-minified, likely-otherwise-obfuscated 3rd party code?

Err, I guess the first part is partially answered already, that pretty printing is on offer. But still, you've got code that's been crammed together, with build artifacts scattered about, rather than a nice collection of organized modules. Then a good chance of obfuscation, whether intentional or from optimization. How do you find a starting point to start digging from in such code?

depends what you're doing and you might already know this, but oftentimes it helps for this unofficial stuff to start with a webdriver, ie https://github.com/clj-commons/etaoin rather than http requests

> certainly-minified, likely-otherwise-obfuscated 3rd party code Not all websites are obfuscated, but when they are it can be painstaking work. You can back track from key events (e.g. HTTP requests, click handlers etc). You can also sometimes find strings on the page and look for them in the code. Sometimes it not worth looking at the code at all. e.g. just letting the code run (e.g. in a headless browswer) and interacting with the DOM or emulating a user actions (e.g. emulating click events).

> oftentimes it helps for this unofficial stuff to start with a webdriver ... rather than http requests > Could you clarify what you mean by this? I don't quite follow

I think they mean - don't look at the requests. Just let the page operate with javascript enabled trapped inside a headless browser (webdriver) then interact with the page.

etaoin does look pretty cool. Any thoughts on using it for discovery of functionality that can then be used without necessarily having a webdriver session?

ChatGPT can help de-obfuscate code. As with all things you put through that box though, take it with a pinch of salt. https://news.ycombinator.com/item?id=34503233

There is a warning in that comment thread > Misleading, ChatGPT generated both obfuscated and de-obfuscated code It's less surprising that it can de-obfuscate what it obfuscated- it's possible it literally had the answer in it chat history that it could use.

Also obfuscated javascript can be megabytes in size (and definitions are scattered order) - there's no way to paste in that much into ChatGPT.

Appreciate that you did say take with a pinch of salt.

I wouldn't paste megabytes of code into chatGPT unless I want to understand and read megabytes of code. What I had in mind was to take maybe one function and then use the output as a starting point. I just tried it with a random piece of code from slack. It did prettify and spell out what each line does but that was not super helpful. Thanks @UJVEQPAKS for pointing this out. I will practice some more due diligence next time.

It asked for more context, though. If there is some more context e.g. a response arrived or something, this might become more useful.

I think your original due dil was good and your post had an appropriate disclaimer (pinch of salt) too. So there's absolutely no criticism from me. 😀 Thanks for the extra info. Agree there may be approaches to integrate ChatGPT into the deobfuscation without trying to give it the whole javascript file.

I think the most powerful/oft-used point of interfaces is hiding conditionals with polymorphism. If your code doesn't have a need for that, then I could see interfaces being rather not helpful.

i look for tasteful uses of them. Reading and think about a non-protocol design

I think it's also important if you want to make a library extensible by users - ordinary conditionals are fine for internals but can't be modified or extended, so if you're thinking about any kind of system that implements its own types or custom data structures protocols can help other users get their data into your system's format. Granted the idioms around just using plain data structures as a lingua franca between subsystems in Clojure are quite strong so there's less of a need for dynamic type-based dispatch than in other languages that emphasize classes but there are definitely contexts where you can't quite do that. One application where protocols seemed to "click" for me recently was in the context of some GUI & graphics programming - I wanted an extensible way to get shapes on a canvas that wasn't limited to a subset of prespecified types of shape and multimethods fit very nicely.

Empirically, they’re not used that often, https://blog.phronemophobic.com/dewey-analysis.html#Var-Definitions-and-Macros , slightly more than macros. They have their uses, but I also think they’re part of the story for convincing OO devs to try clojure. Look! Clojure has polymorphism (even if you end up not needing it as much in practice).

Maybe this can be of some help (although somewhat outdated because doesn't list protocol impl via metadata): https://github.com/plumatic/eng-practices/blob/master/clojure/20130926-data-representation.md

Thanks to all the tips and responses! @UFTRLDZEW : > One application where protocols seemed to "click" for me recently was in the context of some GUI & graphics programming - I wanted an extensible way to get shapes on a canvas that wasn't limited to a subset of prespecified types of shape and multimethods fit very nicely. For me multimethods are a in-between thing! I typically have a dispatch function like this: (:events/type event)` Or maybe some composite thing. But conceptually it is still data driven and not type driven dispatch right? I think of multimethods as a kind of hybrid between a manual jump table (map of keys to functions) that I can mutate with defmethod and a slow version of cond if that makes sense.

My mental model for how for example the #C7YF1SBT3 router works is a mapping like this: route string -> value Or as a ring/router: route string -> function Where "->" is one of the routing implementations (linear, tree etc.) that is chosen for me. This is entirely generic in my eyes and very extensible as I can just ask for a piece of data in order to add/change routes. --- I'll look at the links and tips in your comments and think about it a bit more! Ty

@U2FRKM4TW what I call "jump tables" is actually discussed in the article you linked here: https://github.com/plumatic/eng-practices/blob/master/clojure/20130926-data-representation.md#maximum-mungeability

Yeah, I use them all the time when I don't need something to be extendable from elsewhere.

Used in this websocket example as well: https://github.com/sunng87/ring-jetty9-adapter/blob/master/examples/rj9a/websocket.clj

apparently that's how multimethods work too?

(defmulti table identity)
(defmethod table :on-connect [_] (constantly :connected))
(defmethod table :on-text [_] (fn [message] message))
(methods table)
=>
{:on-connect #function[user/eval7627/fn--7628], :on-text #function[user/eval7631/fn--7632]}

Almost - the registry is global and mutable and you can use derive to establish a hierarchy of dispatch values.