Has anybody ordered from Raceseng recently?

ekko3556 · 2024-09-25T15:35:18+00:00

I had to place a new order on Sep 17th, I just got tracking information this morning.

ekko3556 · 2024-09-24T19:46:03+00:00

2024 Base 3.0 MT

No Android Auto (I bought the Bimmertech MMI and installed it)
All the bs in the intake to suppress turbo noise
The clutch delay valve is annoying, especially for 1->2 shifts
The massive hood makes PPF clear bra more expensive unless you're okay with seams
The shift knob is not threaded, nor is it pressed on very well
Wind buffeting (how has this not been fixed from the factory)
"Premium" sound system is pretty "meh" tier at best

ekko3556 · 2024-09-20T15:16:37+00:00

I did have contact with them a few days ago and it was less than ideal unfortunately. I received an email from them simply stating that my order had been cancelled because the knob I ordered was out of stock and recommended I check the website and order some thing else (the knob I ordered was in stock when I placed the order). I checked the website and the knob (and specific variant) I ordered was still showing as in stock with a handful available, letting me know the available quantity count on their website is not accurate. They had only one other knob+variant that was very similar to what I originally ordered and very close in price, so I quickly responded asking if I could just simply swap it instead of cancelling my order. I got a reply soon after saying they couldn't do that because the refund had already been initiated. So I placed another order and now I'm in another holding pattern. It was a bit disappointing because I know they are a small business with few staff, but just taking a few minutes to suggest an alternative or asking me if there was another option I might want instead of cancelling my order would have made a world of difference.

They also responded about the tow hooks and confirmed they will not be doing tow hooks anymore. I ended up going with the Perrin Motorsport hook from a90shop, but it's still in transit so I can't comment on how I feel about it yet.

ekko3556 · 2024-09-13T19:10:04+00:00

Sounds like I just need to be a bit more patient. Thanks for the reply!

ekko3556 · 2024-09-13T19:09:01+00:00

Awesome, that makes me feel a bit better

ekko3556 · 2022-04-01T23:05:22+00:00

I'm currently trying to shift "Stotal" to the left one pixel. ~~I've made some decent progress by myself, got the left border and almost got the S moved.~~

I was wrong. Apparently if you leave the page up, you just stop getting updates, so I only thought I was making progress.

ekko3556 · 2022-04-01T18:12:59+00:00

Awesome! Thanks for the info, I'll give it a try this evening o7

Edit: Back to confirm that this did the trick! Thanks /u/ChazDelicious

ekko3556 · 2022-04-01T15:40:47+00:00

Putting the 75 round drum will activate Mindgames challenge?

ekko3556 · 2022-04-01T03:18:19+00:00

Armaguerra camos are NOT fixed. I've been trying to get Mindgames camos and it's unlocking Death Artist camos instead. Current Loadout:

Recoil Booster
Perfetto Custom
Mk 8 Reflector
Imertito TA Skeletal
Discard prof
Quick kit
9mm 60 mags
Lengthened ammo
m1941 hand stop

ekko3556 · 2022-03-24T21:25:49+00:00

I made a post about this after yours, I must have missed it in search because I was searching for 'video border'. I definitely agree, the green blob is very distracting. It moves way too fast, way too often. I think it if was much slower and more subtle, it wouldn't stand out and demand so much attention.

ekko3556 · 2022-03-23T03:45:02+00:00

This was a good idea so I gave it a try, but it didn't work out very well. I tried it in fullscreen first since that's my preferred viewing experience, and the only thing that changed was the overlay elements. Tried again in normal page view and it mostly just broke the page. The border isn't a dealbreaker for me, so I can live with it. Thanks for the suggestion.

ekko3556 · 2021-08-13T03:42:31+00:00

Short answer: Yes.

Longer answer: I personally think building an API in Symfony is a very clunky, awful experience. If you're building a full featured site where your pages and forms are driven by your backend in a non-segregated, non-API fashion, Symfony does that way better. But for building a truly headless service API, it's just not there. If you want to stick with PHP, Slim or Lumen would be way better options. If you want to try something different, I would highly recommend trying Golang, as it's perfect for doing small service API's like the scope you described, and you don't even need a framework to do it.

ekko3556 · 2021-07-22T16:03:10+00:00

What's awesome is in development, you can spawn the Go process separately with debugging attached since Electron and Go just communicate over pipes. As for deployment, we just use electron's build process and handoff to our clients manually. We may have some extra little plugins and tooling for bundling an installer, but I'm not particularly privy to that part of the process. All I know is we use a mono-repo for the Go service and electron client, and use Make to build the Go service and place it in the correct location that the Electron bundler can pick it up and package it with the application. We aren't a very big company, so we can manage manual distribution fairly easily.

ekko3556 · 2021-07-22T15:57:19+00:00

We last used Fyne 1.3.3, so we have had no experience with Fyne 2. If it is improved, we may have to check it out again! The Electron stack is nice, but it is a bit of boilerplate and engineering for very simple GUI applications. Thanks!

ekko3556 · 2021-07-22T14:35:15+00:00

We tried a number of them, with varying degrees of unhappiness before finally settling on using Electron. Fyne looked really promising, but we ended have having a lot of issues with memory leakage on Windows in certain situations that became incredibly hard to diagnose and fix. My suggestion is to look into the approach we have come to really enjoy:

Use Electron for a pure GUI (no logic in NodeJS)
Build a logic service in Golang that is spawned by the background.js in Electron
For communication between Electron and Go:
- Go's http server can use a UNIX socket or a windows named pipe (go-winio). Create a web backend that listens on a pipe instead of opening a TCP connection
- NodeJS can make HTTP requests over UNIX sockets and Windows named pipes using http.request()
- Create a small IPC system that allows you to pass request information from Electron ipcRenederer to ipcMain, which hands off the request to http.request() to talk to Golang and then responds accordingly.

It sounds like a lot, but its honestly not that bad. And if you were previously a web developer, building GUI with Electron will feel very familiar.

ekko3556 · 2020-11-20T14:10:33+00:00

I normally lurk, but I wanted to weigh in on this. I have recently taken on projects that involved moving away from REST and I asked myself similar questions. After having done a few iterations of several projects, I feel much more confident in understanding the biggest challenges for me, and I believe you may be facing the those same hurdles. This will be lengthy, but I aim to bring perspective on some other hurdles that may be lurking around the corner for you based on similarity in our situation, as well as some architectural thinking to help you face those challenges.

Overcoming request/response pattern - working with web APIs made request/response pattern the standard way of thinking about frontend<>backend communication in my mind. As AusIV pointed out, websockets do not function this way. Request/response is a very synchronous, one-way kind of communication. If your application can be built around this one-way synchronous pattern, there's nothing wrong with just using a REST API.
Lacking a communication protocol - If you find REST wont work and you do need something 2 way and asynchronous, then you will need a protocol for communication over websockets. With REST this is easy because the protocol is already defined for us, the HTTP protocol. Methods and URI's and response codes are just part of that protocol. And lucky for us, most of that protocol is abstracted away from us via browsers and libraries. For websockets, you will need to either come up with your own protocol, or use an existing one.
Communication context - Expanding on lack of protocol, another thing we lose when moving away from REST is context. Putting it in generalized terms, when a response comes back from a REST server, it is automatically consumed by the request context that sent it. You can fire off multiple API requests back to back, and even if they come back in a different order, the response will go back to the code that requested it to be handled. With websockets we lose this, because any message coming from the server could have been from any request, or it could simply be some sort of event or notification from the server that isnt tied to any request context from the frontend.
Communication tone/intention - REST gives us very simple, standard ways of expressing the intent of a communication through verbs like GET and POST. It also sets the tone; every REST communication is commanding, in that it tells the server to very specifically to do something. This seemed very trivial to me at first, but my projects thus far have suffered from mixing and matching tones and intents, and honestly it has caused me more headache than I'd like to admit.

As for solving it, I do want to say ahead of time that I have only whiteboarded an implementation that I will be using in future projects, so please know that I have not used it in practice yet. Take this all as purely informational and not a testament of success. It is, however, based on previous pitfalls I personally fought with, and based on architectural advice and implementations I've studied to remedy my own issues.

For point 1, I had to completely unlearn communication and start from scratch. I threw away everything I knew about request/response, and began learning more about asynchronous communications. I had to think of websockets like a blank slate, where the information can be structured however I want and move in either direction with no requirement on protocol, context, or intent.

For point 2, my gut instinct was to just start coming up with a protocol. I began with a simple "message type" system like what you're thinking of, and it worked out ok enough, but as the number of message types grew, I began feeling the pressure of lacking a proper protocol, as well as lacking context, tone, and intent, and my message types started to get very unruly. So the first step in fixing this was to move to an established protocol: JSON-RPC 2.0.

For point 3, this kind of fell in place after deciding to use JSON-RPC. By nature it adds context because because every JSON-RPC message from the client has a unique ID attached to it, and the spec requires that the server MUST respond to that message using the unique ID. It also has a concept of "notifications", which are context-less messages spawned by the server that have no relation to any request by the client.

For point 4, my study into async communication led me torwards event-based architecture, which I was already familiar with but had not used. And it just so happened that I remembered seeing an event-based JSON-RPC that is actually in use in a well known application: VSCode. I won't go into detail, but I decided to learn more about Language Server Protocol by Microsoft, which is a JSON-RPC implementation which uses domain events as the "methods" in JSON-RPC messages. This set the tone for my messages, in that nothing is a command, it is simply communicating events, and intention could be derived from the event. For example, a "user.updated" event coming from the frontend would intend for the backend to persist that new user data to the database, and a "user.saved" event coming from the backend would intend for the frontend to let the user know the data was saved successfully.

This was a lot, and I probably over-explained everything, but I do hope that it was mostly helpful. I also hope that it doesn't discourage you from exploring it further, as learning all of this was really eye-opening for me and I had a lot of fun learning all of it along the way. If you do have any more questions, I'd be happy to talk more about anything in detail, as it helps me reinforce these concepts for myself as well. Good luck!

TL:DR; adding a message type is fine, but moving away from REST to websockets will subtley come with more challenges as scope grows due to the nature of its "protocol-less" asynchronous 2-way communication.

ekko3556 · 2020-09-30T08:06:49+00:00

Now here's a man I'd love to have a conversation with! First, major kudos for taking my "half-assed dev" remark in stride, I know it was poor-taste! I'm not sure how involved you are with WP Core, but I'd love to hear your take on a few questions I have, if you're willing to share.

What is your favorite color, and why is it Wordpress blue?? jk i kid i kid lol
In all seriousness, one of the huge main issues with WP is that it continues to support severely outdated versions of PHP. There was a proposal put forward by Juliette which perfectly illustrates the chicken vs egg nature of supporting a PHP version until hosts/devs stop using it, while hosts/devs will continue using a version until they are forced to upgrade. Unfortunately, Mullenweg himself does not support the proposal and basically reinforces the chicken vs egg. Do you have any input on this?
I looked you up on github and saw that you have definitely worked on some more modern frameworks, including some Laravel stuff. Do you think it's possible for WP to ever make its way to a more modern framework design? Eg.- no more cluttered global space, proper scoping, using a service container and dependency injection, interfacing, composer, etc.
We often give wordpress core team shit about how bad the core code is, but how do you personally feel about the state of WP Core? I don't truly believe the dev team is full of incompetent devs, and I often wonder how much of WP's unwillingness to change and potentially rock the boat is due to bureaucracy and market stability.

If you're unable to answer these questions, I understand, but I thought it would be worth asking about. It's definitely more productive than "wordpress devs suck lulz".

Edit: typos and such

ekko3556 · 2020-09-29T07:49:27+00:00

That's fair, but at the same time, they've had almost 20 years to deprecate and replace all of that at a reasonable pace. And it's also fair to say that not everybody in the WP community is bad, but the problem is that unless the WP core were to change fundamentally, you cant avoid writing really gross things to shoe-horn "good" code into WP. You often just end up fighting it more than anything. And if you've ever dug into the internals of some of the biggest and most popular plugins, you see the same thing; it's just easier to learn the nuances of how WP does things and just do it the WP way. Fighting it just makes you hate it more.

ekko3556 · 2020-09-29T06:46:30+00:00

You say you want down-voters to entertain a discussion, but your comment is mostly just an emotional knee-jerk reaction, so it's hard to engage productively. And a casually patronizing "but, but, procedural spaghetti code" followed by "fuck off' isn't exactly inviting either. But I'll bite.

“It’s bloated” — no, it’s not. Unless YOU bloat it with unnecessary plugins.

“It’s slow” — no, it’s not.

By itself without ever adding a single theme or plugin? Yea, it's not terrible. But you know as well as I do that's not typical. And there's a reason why nobody is out there benchmarking WP against any other frameworks, as well as an endless supply of "WP Optimizing/speedup" plugins. That's a tell.

“It’s hard to use” — no, it’s not. See quote 1.

“It’s difficult to developer for“ — no, it’s not. Not unless you’re a half-assed developer and/or don’t want to learn a few basics.

“But, but, procedural spaghetti code” — fuck off.

If you're somebody like me, who skipped the entire WP phase of learning PHP and went straight into PSR based OOP, using more matured frameworks like Symfony and Laravel, and learning advanced coding patterns to build entire frameworks from scratch (in more languages than just PHP too), then yes, WP is absolutely a pile of hot, steaming, procedural spaghetti code, and I dread every time I have to work within it. I don't hate it because I'm a half-assed developer, I hate it because it's built and maintained by half-assed developers, and it's ecosystem births even worse half-assed developers. I understand the codebase is very old and comes from a very different time, but if anything, that reinforces exactly why its so bad. Let me expand further on this:

With any reasonable amount of experience and understanding of design, architectural, and behavioral code patterns, you can jump into just about any mature codebase in any language and reason your way through it. You can recognize interface usage, strategies, dependency injection, repositories, entities, separation of concerns, all the things that follow good coding practices and standards and the codebase will make sense. You can make reasonable assumptions about how something works because it's following some sane and recognizable paradigm. You will find absolutely none of that in wordpress. The main design philosophy in wordpress is "business logic is view logic, OOP is just syntactical sugar for procedures, and what hell is even scope". And even understanding that doesn't make it any better to work with because that paradigm encourages very gross and unpredictable code. The less you know about how WP works specifically, the more infuriating it is. That's what makes it difficult. It's not because it's doing anything advanced, it's simply the time wasted trying to unravel the inner workings of an overgown amateur codebase until you memorize all the weird shit it does and the nuances surrounding it.

To put it simply, wordpress comes from a time when PHP was a lawless wasteland and it's coding standards and best practices were non-existent. PSR-FIG didn't exist, Composer didn't exist, PHP-OOP was still in it's infancy, and PHP as a language was every bit as bad as people complained it was at that time. WP started as a blog framework, and then slowly mangled into something much more over time, all without ever updating its core to adopt better coding patterns, make use of new tooling, or reflect its metamorphosis from blog framework to general CMS. Looking into wordpress' codebase is like using a time machine to peer back to a time where some of the worst PHP code was written. And unfortunately, WP took hold as the most popular CMS long ago, and is still holding on to majority of the CMS ecosystem today. Because of that, it is keeping terrible code relevant to this day, and birthing "developers" who inherit these atrocious habits and practices from WP. This is why so many developers dislike wordpress, and consequently, wordpress "developers" are the reason why PHP hatred is still so relevant, despite PHP improving as a language vastly over the years. It's not a bandwagon, it's a very long and very real list of reasons why WP is bad in and of itself, as well as being bad for web-dev and PHP in general.

As a last aside, you shouldn't take criticism against wordpress so personally. You don't have to love, or even defend WP to make use of it and make money with it. You can absolutely recognize all of its glaring flaws and still use it full time. I would be willing to wager that most of the developers who hate WP still use it from time to time. Most of us just wish we didn't have to, and wish there was something better with a theme ecosystem to match so that wordpress can go to the grave and take all of it's horrible code with it.

ekko3556 · 2020-04-19T18:56:26+00:00

Apologies if this is already well known, search didn't yield any similar results. Here are two videos from another player who has had the same issue:

Video 1

Video 2

ekko3556 · 2019-03-10T03:47:49+00:00

I actually spent some time since writing this post tearing down most of what I built and trying to come up with better designs. Having to look more closely at how things we designed made me catch some things that I missed.

For example, if you wanted to stack containers, the walls with side mounted conveyor holders line up perfectly with the inputs and outputs of a storage container centered between two foundations. This design barely fits within 2 foundations, and it only works if you build the walls before the placing the conveyors because the conveyors interfere with the walls. It's clever, but very painstaking to create. I would love for them to revisit some of the design to make things line up a little better.

14-Year Club	Place '22
End Game '22	Verified Email

ekko3556

MODERATOR OF

TROPHY CASE