nakedgremlin

I thought this was a great write up on the current state for artists and AI engines. I'm honestly surprised by this nugget:

> A free Tess subscription to use their own model for brainstorming and scaling repetitive work (roughly 1 in 4 artists took advantage of this)

So based on the math I'm seeing... the 21 artists in the system, only 5 ("1 in 4") optioned to use the tool for their own productivity? That seems really low and makes me wonder what the user experience for creation feels like. I would assume if you decided to commit to this endeavor, you would want to see what derivative results will look like.

Yeah, my experience on testing GitLab CI/CD script logic is to use a sacrificial branch and grind through test commits until it works, then Squash commits when merging back into main branch.

It's so sad that we can't just run local validations on the CI/CD script through a local emulator. If they had a local emulator approach similar to what is provided by Firebase for their cloud products, that would be amazing.

Yeah, this one caught me off guard. We just purchased a MacBook Air in the last month and if we bought the same one now, we would save $200. Apple support would not price match/correct that, so we will be returning it and purchasing anew.

"The deal is worth $7.2 million..."

I'd love to know more on the business-front for deals like this. Is that a yearly cost? What's the typical expectation for support for something like this?

This definitely isn't my realm of experience at all, so I don't even know if this is a big deal or not. The fact they noted the "bragging rights" makes this feel like a low cost.

Thank you for providing pre-set examples on your site. That's one of the major barriers on these types of tools to "test" especially when you're not sure where/how/if the images are public.

Not sure how I feel about this. Figma is great and all their feature releases have been impressive, but I feel it was due to competition and worry about similar products coming in from big corporations (like Adobe XD). I feel this competition really push Figma hard.

Now being part of the same owner, just makes it feel like any aggressive progress will just stall out.

Oh it feels great to learn I'm not alone in this problem. I completely agree with everything noted here.

The current interface provided for removing the artifacts on GitLab just does not work. There is no feedback; no confirmation. We just uncheck a box and just cross our fingers since there is no other step noted.

Even with the new guidance provided, it's still additional jumps through other codebases just to see if it works. I'm now worried that if I go through this new process, I'll end up right back at the same issue.

We've been struggling with this GitLab storage change, even consulting with GitLab reps on strategy logic between namespace versus repositories. It's still very confusing, especially if you were using their other offerings like CI/CD build systems and associated build artifacts storage.

The artifacts storage is that one that's just tough to figure out when dealing with large builds. We have already offloaded all our CI/CD to our own hosted GitLab runners, but apparently storing the artifacts afterwards (which by default GitLab always stores the most recent builds) MUST use their storage, we can't offload it to our own servers.

The instructions for removing the most recent artifacts also just never works (https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#k...)

So in our monorepo with multiple Windows and Mac applications, we are now stuck with lots of GB that are just there, currently unable to delete.

This is causing us to dramatically revisit our strategy of using GitLab and might force us to other tools.

Gah. The "JSML" name out-loud just sounds so wrong.

We recently used Turborepo -- https://turborepo.org/ -- for a project that started as a two Electron-based builds that quickly escalated to a three Electron-based build. Once we had it set up for the two, it was quite easy to add one more. Our shared components were in a central package while custom ones existed in their respective app directories.

The nice thing with this type of separation for us is being able to target CI/CD scripts to specific apps. Previously we were using targeted dev script logic to initiate the different app builds which just wasn't maintainable. This new approach this time around made for Electron deployments to be super simple, consistent, and repeatable.

All this was done by two team members on dev side.

Would you be willing to share how that compares to your iOS side? I see you have Apple Watch support which I assume is easier to monetize for your space.

I'm excited overall about these 'leaks' and details surfacing from Apple and Meta. I'm optimistic the AR side will win (versus VR only), but overall, by being shepherded by these big orgs, I expect hardware costs to reduce dramatically for end users. Lower costs will pull in more users and allow us to really design experiences for a wider AR audience.

Sorry for the tangent, but can you provide more info on your service? Without signing up from an account on your site, I'm unsure on how the interface here compares to GitLab runner registration (which I always felt was a bit convoluted due to how GitLab structures their user and organization accounts) and how the hardware compares to what GitLab offers.

I love Kevin's life lists, but it always feels overwhelming to parse through. Too much lovely nuggets to internalize.

Love the product video: https://www.youtube.com/watch?v=UKKFNV0m3SQ

"Bulky design" "Colors"

I think the different hug styles also depend on the heights of the individuals. I personally think it's tough for a criss-cross hug approach when the height differential is more than a foot.

One of the linked articles has a good visual reference: https://www.science.org/content/article/how-hug-according-sc...

I think this is an incredibly well done comic-book style walk through analysis. I know a lot of the comments here are about this presentation not being mobile friendly, but one of the tough pieces here is that it's an analysis of a flow that ranges from email to website with commentary on top... that's honestly tough to do without a structured format.

I really appreciated the alternative design directions offered and supporting documentation. It really helps reinforce there are best practices and reasons for these dark patterns to exist, albeit for the wrong (or right? depending on your place in an org) reasons.

Incredible work. Coming from a POV of a person who has to wrangle a lot of VFX heavy creative, it's great to see the technical walkthroughs like this, especially the workflow overviews to see how it matches with our render process.

Oh the fond memories. I remember being able to develop immersive multi-touch experiences and prototypes using ActionScript 3; there was a cottage industry of businesses supporting these types of application builds. All this existed before the surge of JavaScript innovation and, of course, the entire modern mobile app ecosystem.

Interesting. I didn't realize you can use GitLab CI/CD on non-GitLab repo. Do you happen to have a documentation on this (my searches came up empty)?

Does anyone know how to see historical runner usage on GitLab? I'm digging into the interface, and I only see current month usage, no ability to go back to previous months. With this reduction news, I thought the interface would have updated with better details.

Yup. We encountered this exactly on our initial set up for our company. This made us decide to domesticate our company from Delaware to California, with a little bit of money lost for this learning process.

So... this is pretty much saying they will now analyze all links now, irregardless of "nofollow". Previously they outright ignored "nofollow".

So... similar to Hewlett Packard Pathfinder for Hewlett Packard Enterprise?

Hackathons rarely need to deal with such rigor. I've participated in quite a few and the it all boils down to understanding the judging metrics (and personalities), the bite-size tangible demo, and the marketing pitch. If you have a team that does that well, winning becomes an achievable and repeatable end result.

Saw this at a Slack Dev meetup. Really promising stuff especially with the Wit.ai integration.

Agreed. A lot of the interactions shown matches previous Push Pop work (some almost exactly -- page to image to full screen). But I do find it odd that it'll take them close to four years (from acquisition) to get this to market.

Of all the pricing structures, I really enjoyed Maciej's approach. From the site:

Users pay a one-time signup fee of around ten dollars. The fee goes up by a fractional penny with each new user.

The signup fee helps keep the site from growing too fast, and keeps Pinboard spam-free.

https://pinboard.in/about/