|
Huragok posted:I'm building an iOS app using Objective-J  The rest of it is understandable, but man. I had no idea anything used Objective-J, outside of the handful of Cappuccino apps out there.
|
#
¿
May 4, 2012 09:31
|
|
|
|
| # ¿ May 10, 2024 06:34 |
|
|
ToxicFrog posted:
 This is basically "client-side templating 101." Though really, "reconstruction of data" shouldn't be needed if you have an API that's spitting out a format your JS/templates consume, and it can get ugly if it's an ad-hoc implementation and not based on one of many libraries that do this.It's done so that no duplication of effort is required when making web applications that have lots of front-end interaction. You generally don't want to have to have both server- and client- side templates doing the same thing. (of course if this is a mostly static page with no rich interactivity then yeah it's way more effort than it's worth  )
|
|
#
¿
Oct 26, 2013 05:12
|
|
|
Misogynist posted:This code just turned up in some code I'm writing to integrate Crossroads.js with Backbone In that case, if they really want the extend helper, it's not a "public"/exported/global'd helper in Backbone, so I suppose that's one way of doing it.Curious, how is that integration going? I'm extremely frustrated with Backbone's lovely router, having been used to Ember's wonderful, promise-ified, basically magical router, and have been looking for an escape. I've been considering trying to get router.js (which Ember's router is built on) working with Backbone, but that seems like a dark road to go down. abraham linksys fucked around with this message at 01:41 on Jan 26, 2014 |
|
#
¿
Jan 26, 2014 01:38
|
|
|
It's cool to write scripts in Node because it's really easy to write asynchronous or event-based code in it (for, like, a file watcher), Node is a fairly small runtime and easy to install, and NPM/Node modules don't have the dependency issues that Ruby or Python do (i.e. no virtual environments or Bundler). Sometimes it's not cool to write scripts in Node because you have to install Node and JavaScript is not a well-made language. I really don't think the argument goes any deeper than that 
|
|
#
¿
May 16, 2014 04:16
|
|
|
i write huge PR descriptions because when people `git blame` their way through figuring out what the gently caress happened via GitHub, they tend to look more to PRs than JIRA tickets, because GitHub PRs take about a second to load while JIRA takes like seven also for code reviews! no one loving clicks the JIRA ticket when doing a code review. all of our PMs suck and write terrible AC anyways so even if you did you probably wouldn't be able to understand what the gently caress is happening
|
|
#
¿
Apr 28, 2021 17:16
|
|
|
we do squash-merges so every individual commit on main has an associated PR anyways if github could automatically pull the PR description into the commit message that'd be nice, but the way git/github handle commit messages is stupid as gently caress anyways, so that ship has sailed
|
|
#
¿
Apr 28, 2021 17:25
|
|
|
necrotic posted:It can for squash merges, I think? It's a fairly recent setting. AFAIK unless there's a buried setting, squash merges just have a default commit message of "the commit message from every commit in the branch." Which makes sense because GitHub doesn't render commit messages as markdown, so just pulling a PR description into a git message would make it harder to read (not to mention not include hyperlinks or images...). There's a world where GitHub just renders commit messages as Markdown, shows you commit message details in the PR more visibly, and people make tooling for Git that can render Markdown, and then I never write a long PR description again (outside of maybe reviewer notes & remaining TODOs) and all of that history lives inside Git instead of GitHub as it should. Unfortunately that's not the world we live in  Xarn posted:MS is the first place where I was on team that uses squash merges, and I am not a fan tbh. Turns out that you can't just fix bad commit discipline by squash merging, because while you might end up with okay commit messages, your commits are now HUMONGOUS. It's weird, I started up a new repo for a new project and while I've encouraged the engineers I've been working with to use squash-merges for messy branches, I've been debating whether to disable regular merges entirely like we do on our other repos. I personally like to rebase and fixup and all that poo poo (one of my coworkers has a really good workflow for this I need to figure out; something about using "git am" as like a cherry-pick on steroids?) and make a bunch of individual clean commits, but I'd much prefer squash commits for 80% of the feature branches I've seen. It does make the commits loving huge, especially on the frontend projects I work on where there's a lot of refactor churn and a lot of large feature branches due to the difficulty of doing feature-flagged releases for large-scale changes. That said, the flipside of this is that when something inevitably breaks in a massive merged change, it's very easy to do a git revert against the one squashed commit
abraham linksys fucked around with this message at 17:53 on Apr 28, 2021 |
|
#
¿
Apr 28, 2021 17:50
|
|
|
microsoft is sort of trying to solve the packaged chromium on windows with WebView2, which will use system-installed Edge (so, Chromium) by default. applications can still choose to package a specific version if they're concerned about updates breaking the apps, though teams is moving to it. i laughed very hard when i saw a headline saying "Teams Preview Ditches Electron!!" and thought "oh wow microsoft must have finally built a native UI framework they like enough to actually build software in it again" and no of course not they've just moved from Angular to React and Electron to WebView2 https://techcommunity.microsoft.com/t5/microsoft-teams-blog/microsoft-teams-advantages-of-the-new-architecture/ba-p/3775704
|
|
#
¿
Mar 30, 2023 04:22
|
|
|
the development history of prisma is so insane that i am unsurprised that that's what they're shipping, what a loving company/project it makes slightly more sense as an architecture if you know that prisma at one point had aspirations of supporting other languages, but afaik they only ever got as far as a half complete go library that appears to have been completely deleted from their website, and the lead developer on the project at prisma was given ownership of the project after exiting the company which is very funny
|
|
#
¿
Jan 18, 2024 18:47
|
|
|
personally i would not use the ORM created by a company that originally raised money to be a GraphQL-based backend-as-a-service, then pivoted to being a GraphQL query engine as a serice for existing databases, then pivoted to being an ORM for all databases and languages, and now appears to have burned $40 million dollars in venture capital on building a TypeScript ORM anyone remember "gatsby"? love that they got a bunch of people into their open source project, then when everyone started having more mature sites and their build times started creeping up, they introduced a paid gatsby cloud project that was the only officially supported way to do incremental builds, and then they got bought by netifly and now the entire project is very dead 
|
|
#
¿
Jan 18, 2024 18:52
|
|
|
|
| # ¿ May 10, 2024 06:34 |
|
|
how soon we forget the incredible technology that was Google Web Toolkit
|
|
#
¿
Mar 24, 2024 16:05
|
|