Similar to how you guys made the twitter bot, would there be a simple way of sending an automated http request to discord to change a setting? Just a simple node script with https module on a cron job? How would I figure out my auth token or w/e? This is not stuff good at.

(specifically I would like to turn on DND at 1am weekdays and turn it off 5pm, which of course slack you can do in settings and not on discord)

Yeah I'd do it as you described. Use Google chrome tools to spy on the http requests and responses, or possibly they have an API which would be simpler, probably

Cool I'll look into doing that. Looks like their api helpfully can only change your avatar not actually change your settings.. lovely. https://discordapp.com/developers/docs/resources/user

Yeah - if you look at forum.go in my code above, basically everything in there is a result of using Firefox dev tools to examine the requests that my browser makes when logging in or submitting a post, then figuring out where those values come from (most are cookies or included in form responses, the security token is embedded in Javascript in the page that I grab with a regex) and recreating those requests programmatically.

That's if they don't have an API to do this.

I'm too dumb to understand go but I'd assume you do something like


Send post to log in with username and password

Take token data from set cookie response headers or response body or whatever

Then use that token to do a post to post the contents of the tweet to the politics thread id


Every time? you don't persist the login token/info anywhere right?

So I got an offer for 1M (my currency) plus 8% annual targeted bonus and stock options. I'm currently being paid 0.9M flat. Plus the new company has more exciting tech. Pretty sure I'll take it.

Market rate for total compensation is 0.96M for my experience btw.

bolded is ding ding ding. I learned this the hard way when I submitted a massive PR with like 25 files and it took almost 2 weeks to get through it with all the suggestions.

proly not a good idea to be the code reviewer for your own code. tho I may be misunderstanding.

also, proly not a good a idea to let the guy a few months out of college code review.

Congratulations Wolfram!

I persist the login cookies (which I think are valid for ~a year?), but not the security token (which I found out the hard way expires fairly quickly).

What you described is correct for the first run, where I don't have saved cookies yet. For future runs, I...
- load cookies that I previously saved to json file
- load random 2+2 page to get security token (I set it to the PM homepage, as Chips Ahoy's code had, but most/all pages you load will have the token embedded in them for you to grab)
- submit post

Disagree - code review for junior devs can also be a place for them to ask questions about why things were written a certain way and learn from more experienced devs by thinking more in-depth about the code they're looking at

you misunderstood my post - i assign people to review. I only am reviewing simple stuff like documentation, simple one liner changes, and stuff that's blatantly simple and no one wants to bother with (like updates to README files or some of our wrappers for java which I understand pretty well)

Yeah agree with this. Though I think what Victor is getting at I also agree with. Which is that very junior devs should be assigned code review but not responsible for giving approval.

And before anyone nitpicks yes we have pulls for documentation but because they’re mostly written by our interns right now and theyre a disaster

That sounds about right. Whether you persist or not probably doesn't matter since you're going to do this like... 2x/day

There is a websocket gateway implementation and it supports sending away statuses. It's a bit more involved than the API - it's basically what you'd use to make your own discord client.

https://discordapp.com/developers/do...#update-status

I really only glanced at it but I think basically you connect to the gateway and you can listen to or send messages. It is not clear on first glance whether all these messages can be sent as well as received.

One of the things I love about my job is that I was very quickly responsible to review the code of others who who much more experienced than me.

For anything beyond trivial my process is usually this:
Make sure I have a branch that is identical to what they are merging into.
Make a new branch locally and pull their PR into it and then merge into their destination.
Build in one terminal (sometimes with breakpoints always with tests and linting)
Open the project in another terminal
Have the PR diff open in github
Review the code, quickly test the end user experience that it is supposed to be solving/fixing. Try and consider any gotchas in the UI that could cause a weird state.

Click accept, click merge

Nice!

Yeah, I agree. But I think most of the value in code reviews is in knowledge transfer and catching significant issues (perf problems, bad logic, security problems, etc.) and not in just checking for conventions / code style issues.

Edit: We give junior people responsibility for doing approvals too. Senior people know what PRs are appropriate for more junior people. It’s also good for experienced people to get reviews from junior people because it can force them to make it more accessible to them.

Interesting. Im curious how many other people do it this way.

We give approvals and then it’s up to the original dev to merge.

I like this approach but it’s probably relevant that merging means it’s getting released and so the original developer needs to control that.

Yea merging here is several levels below release, several.

yea me too - JJ, when you merge to master it goes to release right away, or fairly quickly?? we have an extensive system for releases that I'm just learning this week and have been fairly involved in.

I think they were holding back stuff for me to do until I was officially full time, which was nice of them, because they totally could've taken advantage of me. Now I have so much to do I think I need to go in this weekend and get some stuff done. I am writing a fairly complicated test for the issue I have been pushing to be fixed for the last several weeks, + my PM stuff, + some other assignments I have. I need to review like 40 pages of intern produced documentation and i only got 6 pages in and had a page full of notes already. lol.

Merging to master kicks off a build plus some tests. Any successful build can then be deployed at any time by anybody - typically the dev who merged so that they can make sure whatever they wanted to do happened successfully in production.

Sorry, should have been more specific. Jr and inexperienced devs should not have approval authority. When we say "code review" it means "approve for merge" and I was not conflating it.

Obv I think it's good for Jr devs to read and question code

Why not? Honestly, there are a large number of non critical code reviews that young developers are perfectly fine reviewing.

Totally wrong u less you mean junior to be like less than 3-6 months at the company. After 6 months on a team everyone should be approving code, ideally on just a rotational basis.