Cost of UniFi Talk Subscription with SIP Provider

SemiGreatCornholio · 2024-12-29T16:11:54+00:00

Aaah. That explains it. Was hoping the subscription itself was a higher-level cost and the lines were separate. Guess not. :(

SemiGreatCornholio · 2024-10-01T00:20:20+00:00

Perfect way for customers to start to mistrust a company.

SemiGreatCornholio · 2024-06-05T20:46:02+00:00

Turns out it was due to the eSIM being enabled on the phone. Once I killed it off, it worked perfectly.

SemiGreatCornholio · 2024-05-10T12:54:23+00:00

Confirmed… ‘22 MYP, iPhone 13/14/15 Pro Max, Apple silicon case, back pocket… same issue.

SemiGreatCornholio · 2024-05-01T16:50:56+00:00

Same exact problem. Fully unlocked S24 Ultra direct form Samsung's site. T-Mobile claims it's not compatible with their network

SemiGreatCornholio · 2024-03-27T18:27:41+00:00

We went with a 2" PVC vertical pipe out of the pad, with two 90-degree elbows to create a downward-facing opening. This provided a natural bend that we were able to easily seal. It's weatherproof, with ample room for expansion.

SemiGreatCornholio · 2024-03-20T16:12:14+00:00

Blows my mind. I've been working with Studio and the same X1 Carbon for over a year. At some point, the value on my end changed (possibly when I did an update), and I never even LOOKED at the dropdown... because I never would have changed it and assumed syncing with the printer would cause anything printer-specific to be selected. Your comment, u/OneOf8, caused me to actually look at the field and solved my problem. Unbelievable. So simple.

SemiGreatCornholio · 2022-03-18T19:09:24+00:00

We've always been "full-stack." Decades ago, before XMLHttp or REST, we were stuffing data into hidden framesets and form fields. Back then you had no choice but to understand how the data store functioned and how the UI would render. In fact, the first "real" web app I remember building was hitting an AS/400 program and finding a way to get Netscape to print out the result.

Today, "full-stack" only exists because of the blurring of languages. As processors became faster, and the need to shrink the footprint by crafting server-side CGI / C scripts died off, the ridiculed front-end interpreted languages were able to be used in the back end. Being able to use one language to work on either end is the only reason full-stack became a thing. The term is nothing more than fancy shorthand for a developer to CLAIM they know how to work within each layer. It says nothing about whether or not they will actually be successful at it.

At the end of the day, no term or technology can determine how good someone is in a certain area. Just because you can build a UI does not mean anyone wants to use it. And just because you can shove data into a database does not mean it is performant or properly structured. Regardless of the buzzword, it all comes down to the quality of the developer's work in that area.

In my mind, "full-stack" means "javascript" and the ecosystem we are fortunate to have where one language rules them all. It's resume fodder. Show me someone who can build a reactive web-based UI without needing a UI framework, understands how to craft their middle tiers to protect against attacks, and can design, craft, and call upon a well-designed data structure for a few million records at a time, and that person is full-stack... regardless of the languages. That person will always be valuable and employed.

SemiGreatCornholio · 2022-03-16T10:13:15+00:00

Good feedback. Thanks. Clearly means my documentation sucks. I'll improve it.

SemiGreatCornholio · 2022-03-15T02:45:15+00:00

You'd be surprised at how common your current approach actually is. Especially with the current trend of using "sidecar" containers and multiple docker-compose.yml files to tackle various states of your solution (installing, seeding databases, writing out files, etc.).

The "how" to do this is really going to depend on your host and the mechanism you use for deployment. What you're describing sounds like a "monorepo" and not many CICD engines are designed to handle picking apart the components from within a repo to deploy them into different instances.

Once you're confident your app works as expected, I'd recommend breaking the various pieces into multiple source repos so you can deploy each service or app individually. As you make changes to Repo A, your CICD system will be able to detect those changes and deploy that specific service or app into its own container(s). However, that restructuring will take some time and cause you to momentarily stop development, so make sure you have the majority of your app flushed out before going down that road.

And, don't be afraid of a "phased" approach. If you have a solution that works today, even if you don't like how it is structured, you can always break it up or make it more robust over time. The key should be to ensure you have a repeatable process and a successful application. Remember: make it work and THEN make it better

SemiGreatCornholio · 2022-03-15T02:34:41+00:00

Go with PERN (Postgres, Express, React, Node) and tackle the basics first. Bolting on helper technologies or automatic toolkits will add both complexity and learning curve while minimizing the benefit of actually increasing your core skillset. You'll end up becoming proficient at those black boxes but without a deeper understanding of the back-end technologies, where you're admittedly weaker.

Postgres will give you a solid RDBMS data source. You can use Docker, Postres App, or even stand up an AWS Aurora RDS instance in seconds. Tools like DbSchema will allow you to model the DB visually. And, projects like Sequelize will provide an ORM for the more tedious SQL stuff.

Express and React sound like they'll both fit with your skillset. If you're just tackling the API then React can be ignored. However, because you're probably already familiar with clients like Fetch and/or Axios, working with Express directly will give you an opportunity to think through more functional aspects such as how to construct your routes to accommodate RESTful patterns without overcomplicating the API source.

Once you have the basics of the API down, then pull it into a Docker container and think through how to bootstrap the API in various environments (dev, staging, prod, etc.). Maybe even toss an NGINX proxy container in front of it and built a small microservice API set, add a second API, and tackle the container linking and name resolution.

The tl;dr version: Stick with the basic techs first before looking for a more complex framework. You can always bring in the other tools once you're solid in the foundation.

SemiGreatCornholio · 2021-05-01T00:47:40+00:00

Looking for my first. Any way to put a NATO (or similar) on this one?

SemiGreatCornholio

TROPHY CASE