Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 months ago.
Improve this question
Reactive programming is a very useful way to increase the capacity of webservices because of non-blocking thread. I recently came to know about this programming paradigm and I want to use it for most of the applications I build. Despite being so efficient, I still see new applications being built in a blocking way. What are the reasons that reactive programming is not used everywhere as it's a nice paradigm and very efficient in handling users at scale?
I don't know if this question is too generic or suited for the platform. I tried searching on the internet and could not find any staisfactory information. Therefore, I am asking it here hoping foor someone experienced to help me with it. I am trying to learn Project Reactor for Reactive Spring.
Reactive, e.g, WebFlux, is to solve a specific problem that most websites won't experience. Regular servlet or dispatcher-based frameworks put each request on its own thread, which is generally fine. Soon Java will come with lightweight threads which is claimed to perform better than reactive anyway. Reactive is also based on function programming paradigm, which is a complicated and difficult way to write applications.
Reactive is meant to handle multiple requests on a single thread by using callbacks from I/O operations. If done correctly websites can handle more requests for the same number of threads than non-reactive. This would reduce resource costs and perhaps allow a service to be more responsive since starting regular threads is expensive.
In my experience, in practice, Reactor is not generally done correctly, has far more bugs due to the complexity of function programming, and takes much longer to deliver the code.
In my opinion, it can still be useful framework for simple services that are primarily I/O bound and have very little if any business logic. That is until lightweight threads become standard in the JDK and then maybe you have chosen the wrong path.
Also in my opinion, developers find it fun and exciting due to the functional programming paradigm, as do I. It's not a bad thing to use but shy away from it for important business related code/services.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
As the title suggests, I'm building a simple chat app in Node/Express + React, and I'm using socket.io to get real time updates.
However, other than the chatting itself, rest of my app is very basic (registering, signing in, creating rooms etc), and while it's definitely doable to make all those requests just socket emits, it feels like bit of an overkill.
So I was thinking of creating a regular REST API for that stuff and outsourcing it into a separate file, then creating another file just for the chatting function itself, where I'd use socket.io, but I'm afraid that it may seem a bit unprofessional, or leave an impression that I don't know how to use sockets well enough.
Key point: When finished, this app will be posted to my portfolio, so I'm not very concerned about what just "can work", but rather what's the best and cleanest way to do it? Should I switch everything to sockets and use them even for basic fetching of lists and stuff? Or is it better practice to mix the two, and use REST for, well, the rest?
In my experience, To mix the two is the best way to do that.
I did that in many projects and it worked well.
I surely think that modularity is the best way to make code clean and qualified.
So, to use both of regular REST API and websocket is more professional.
Thank you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
If there is any PLC programmer or Twincat3 user out there. I would like to write my master thesis on Twincat3 in a company. Basically, They have different kinds of the Test bench, and they want someone to develop drivers for them. I have no experience with PLC or C++ or IEC61131 languages. Is it possible to learn any of these in 3 months, and then start writing the thesis? I have three months of Internship time before starting. I am having a bit of doubt. Even though it is daunting as an Electrical engineering student, I have no other options.
I thank you in Advance.
Also, The test benches are mainly Powerelectronics or Electrical machine test bench. I believe I need to automate the test processes in twincat3.
Best Regards
Good choice with TwinCAT 3. TwinCAT 3 is very capable, and quite easy to learn (of course dependent on your background, but generally a good platform to work on).
All I can support you with is a link to a TwinCAT 3 tutorial that I've created that is free of charge (available on YouTube):
https://www.youtube.com/playlist?list=PLimaF0nZKYHz3I3kFP4myaAYjmYk1SowO
There are also some other resources available both on YouTube and on the website. I've created a set of links here to help you find all the resources you might need.
To answer your question I would say it depends. Three months is not much time, especially considering you probably have a lot of other things that need to go in there (doing studies, writing the thesis, implementation, conclusions etc). It depends on the complexity of your project (it's not very specific what "writing drivers for them" means). If it's a simple project (including a very basic set of I/Os) it might be do-able. If it's anything more complex (like needing to add a front-end, doing motion control and maybe even safety) then it's most likely going to be hard to finish it in three months.
But again, I think more details on what you want to achieve is necessary.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
What is the difference between the concurrency models of Erlang, Elixir, and Scala?
This is way too hard to answer from a point of zero prior knowledge. I think the most valuable way to even approach it (because this sort of thing gets asked all the time in a most unhelpful sort of way) is to include some links to reference information about these -- and then close the question.
(If this is such a bad idea in the minds of other SO users that you think we should delete this entirely I'll create a resource page external to SO to use as a future reference-to-references.)
Erlang Process vs Java Thread
Is Scala's actors similar to Go's coroutines?
Future investment: Erlang vs. Scala
Seven Concurrency Models in Seven Weeks
Qt Concurrent (Qt documentation that explains a bit about how the underlying madness of shared memory concurrency is tamed somewhat within that framework)
An Introduction to Asynchronous Programming and Twisted
Parallelism and Concurrency (Haskell Wiki)
Why Events are a Bad Idea (USENIX paper -- good foundational information)
Wikipedia article on Concurrency
Why Microservices? (conceptually relevant, particularly since Erlang and other "actor systems" usually fit the conceptual definition of being swarms of microservices, whether distributed or not)
Concurrency: Time is of the Essence (SICP -- FYI: This entire text is probably one of the most important things you can read as a programmer)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Yes, while i'm working on node.js, i still love perl, :)
The old web product is based on old perl CGI, i'm looking to the simplest way to fix XSS/Sql injection/etc. web security holes, within a week including testing, :(
So for
Catalyst
Dancer
Mason
Maypole
Mojolicious
which one should i use in the ARM platform ?
Thank you !
You have fallen foul of the primarily opinion-based off-topic categorisation, and your question will probably be closed very soon. However I think it's worth offering a few guidelines here
First of all you should absorb what is written in CGI::Alternatives as it is a reasonable summary of the subject
Next you should separate the HTML generation functionality of your existing CGI code from the interface itself, and consider replacements for each of them separately. If you were to use HTML::Tiny together with CGI::Simple then your code would have to change very little and you would have achieved better partitioning of functionality
Ideally you will move on to one of the many templating systems such as Template Toolkit, together with one of the frameworks, which is the topic of your question. In the end you will need to do a lot of research and many trials to discover how well each framework fits your requirement, in terms of both the feature list and the convenience and clarity of the API
All I can do here is say that I am very fond of the Mojolicious suite and suggest that it may be a good starting point. The API focuses on command chaining in a way similar to Ruby, and there is a Mojolicious::Plugin::CGI accessory which will allow you to execute CGI scripts unchanged during your migration
Note however that all of the frameworks that you mention, as well as several others, will have their proponents. That is why you must make the selection yourself, as such recommendations will be influenced primarily by familiarity, and without your own knowledge of the requirements of your project
Unfortunately I cannot speak to the security issues of the various options, but I hope that has helped a little
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
My goal is to create a game in a browser (a game like wordfeud) and my question is what is the best way for the networking part? In Java, C# and so on you can use socket programming (server-client programming), but how is the best way to do it in a browser?
Yeah, node.js is excellent for game server, for the following advantages.
Network IO and scalability. Perfect match for game servers, which requires realtime, scalability, high density network IO.
The node.js thread model. Single thread is quite suitable for game server, it helps us to handle all the troubles about concurrency, lock and other annoying questions. Multi-process, single thread is ideal for game server.
The language advantages. Javascript is powerful, popular and performance good. Further more, if you choose HTML 5 for client, you can reuse a lot of code logic between server and client.
But the original socket.io is single process, if you want scalability and extensibility, some framework may needed. Pomelo is a good candidate for it, it's an open source game server framework in node.js.
Server side: Node.js + socket.io seems appropriate for those types of connections
Client side: javascript or actionscript from the client side.
Example
PopCap (which makes a bunch of popular facebook games like zuma blitz and bejeweled blitz) uses predominantly flash / actionscript / possibly flex for their games and it seems to do the trick. Javascript would be more accessible to those who wanna play via a phone or tablet though.