I have a community management app (#1) and am just in the process of building out a website (#2) that is more public focused.
I would like to reuse some of the #1 features and have a common user management across #1 & #2 for obvious reasons. What I want to re-use from #1 is mainly user management (registration, login, roles & admin features for users).
In the short run at least a lot of the functionality in #2 would be quite distinct so I can see the value in keeping it separate. Keeping them separate but using the #1 API would also potentially simplify development and prevent duplication of these features. If I merge them, any work could potentially break the app (IOS/Android) and full regression testing takes quite a bit of work. Both are using MERN stack so it should be fairly easy to merge them (even in the future if I respect the namespace).
I am wondering if I could face any performance or data issues, by keeping them separate. Is this a major anti-pattern?
FYI, I have a dev background but working with other developers on this. I am not that familiar with this stack although I have played around with it. I know enough to cause problems so I don't want to shoot myself in the foot. As I have to make this decision soon, I really appreciate input from all of you Node & Mongodb gurus. Thanks in advance!
Related
In the past I have used Zoho Creator which worked well but now I need something with a far better front end and something self hosted so I have been trying to find a CMS that can do what Creator does. I am currently using WP Toolset but is a nightmare to do the calculations I need it to. Have tried PRocesswire but no front end. Does anyone know of a CMS that is easy to "Fetch" data from other tables and fields and then return an answer? Or another idea altogether?
I’m aware of a company who is doing just that. The app, delivery and all of it is in the cloud with management locked away multiple security U2F keys away form mere mortals. But the point is, this idea, to make it easier, backer resistant (never proof), and all that 1 it’s on the drawing hoard at some start ups. Not just one. Check into it. I wish I could give you more but I’m part of a team doing just that and it’s outside development that can caused either unseen bugs, too many classes or wrong type of classes, or otherwise screw with our once perfect baby. So we are in essence sandboxinv all developers and forking their repo, even going a step further and giving them a dev repo that’s formed from our actual repo in real world terms.
Hi I've just started a new job and the boss has asked me to find a "base Xamarin Framework" for a mobile app that need the following:
Logging errors (log them locally and then push to a server)
Clearly split Screen/UI stuff from backend stuff (i.e. calling a server or accessing a local database)
Remembering state
Holding user preferences (user settings)
Dealing with timeouts when calling a server
How navigation is managed
Not really sure how to go about finding one or what a good one is, any suggestions would be awesome :)
There's the almighty and beloved MVVMCross. It's widely used in the Xamarin community and it's constantly updated (it'll even have Xamarin.Forms support)
It's a MVVM framework. It means it'll increase the amount of code you can share between your platforms and also make your code easier to maintain and understand due to the separations of concerns. If this is still not enough, it has a lot of plugins that handle many of those tasks you mentioned and a lot more.
I've been working on a drupal site. During the course of editing it i've added data, removed fields, made new fields, removed data, and added more data. Now the site is almost ready to go- but I feel like the database is very messy (with revisions to fields, etc)
How can I best clean-up my site before the official roll out? Also, what are good practices to use while adding/deleting fields so I dont run into this?
This is a workflow related problem. user491844 mentioned the usage of Features and #luksak told it's not a real answer, but I would like to explain why the usage of Features would be actually one kind of a solution to this.
Normally we do multi-stage development, meaning that you should have a separate environment for development and for production (at least; often a third area called staging is used for acceptance tests etc.: development → staging → production). This means you should try new things on the development environment and whenever satisfied with the result, move it one level upwards. This can be done in multiple ways, one possible answer is Features. In general, you should take a look on how code-drive development can be done.
It's very easy to see why this approach would actually solve your problem: in production, you wouldn't have to clean up things often, because it wouldn't have any extra cruft that a sandbox often has. It also adds a layer of protection: if you break the sandbox, you can just clone the production site and you're good to go. Using Features with added version control (probably Git) also provide a fine way to keep things in a safe place, allows documenting what's happening and makes re-using the different segments of your site possible - which is going to be a very good thing later if you're building multiple sites.
If you have a complete site, it's possible to "Featurize" it, but you will have to be very careful on how you build up the features. In general, try to build small features which only contain components related to a given functionality. You will end up with a lot of small features this way, but it makes handling dependencies easier. You can find a lot of articles on how to split up your features properly: like this and this. Good organization is essential.
One thing I would also mention: in production, you will probably want to keep the site as lean as possible, so setting up caching, disabling development stuff and UI components of some modules etc. might be useful. You can find several useful modules which can help you in production, one of those is Production check.
There are a lot of articles on this "how to move to production" topic that you should research to see the recommended steps, see this for an example.
I've recently been given the role of managing or development environment which includes:
Managing the version control system (subversion) in which we typically have one major branch which is released to production every 6 months, a maintenance branch which is released every 2 month to fix non-major bugs found by users and a couple of branches related to bugs which just can't wait for the maintenance release.
Managing our databases so that we have a development database for each branch of the code
We've not long moved over to using the version control system and have had the following issues:
Developers who work on a number of branches concurrently can quite often end up developing against the wrong database (we have around 15 developers)
A lack of a decent strategy for managing the release of branches into production and the propagation back into other branches
A lack of a decent strategy for managing the databases associated with each branch (i.e. should we keep a script which is aligned with the production environment and then a script to bring each database user in line with the needs of the branch)
I had thought of using a Virtual Machine for each branch of the code (i.e. A VM containing an Oracle Express database user, a Coldfusion Administrator with the correct setup for things like data sources, and development tools like the IDE and Tortoise).
I was looking for any suggestions anybody might have to help with any of these issues as I'm finding it really difficult to manage the process. I understand that no 2 companies have the exact same setup but I'd welcome any help.
I think that the best solution for you can be to start using continuous integration applied to your product life cycle strategy.
You can read about it over the web:
Continuous integration
Great open-source framework for continues integration!
I hope this helps you, but your question is quite hard to answer 'cause there are a lot of parameters to answer which always very from company to company, you should consider hiring a consultant to help you. He/She will have to come to your company and help you decide and implement.
I would start by asking each of the developers why this kind of mistake happens. If a developer has recently made the mistake, then get them to explain how they did it and what might help them in future. Also talk to developers that have not recently made a mistake.
I'm assuming that you have a server with Oracle and all the different flavors of the db running on it using different port numbers. In that case you would create a new db instance to go with each branch and the problem is how to help the developer set up a context before working on the branch.
Tortoise SVN is a nice tool, but perhaps this is a situation where it would be better to have some kind of small app that does the checkout, and remove Tortoise from the machines. The small app could keep a window floating on screen showing the currently active branch, and it could handle checkout and checkin, as well as making sure the right port number is used.
I'm new to production level web development, so sorry if this is obvious. My site has a potential to have a sudden surge of (permanent) users and I'm wondering what happens if too many users sign up in a short period of time, causing the site to run slowly. Since development takes time, would it just be a case of adding more boxes to the server, or does the site have to be taken down for code improvement?
Thanks
Don't worry even very popular sites go through this. Coding well is always a plus, but sometimes even that is not enough. Twitter being an ideal example, they started their messaging on Ruby but had to move to Scala as they became more and more popular.
Since you say you are new, can I suggest getting yourself familiar with caching queries and caching static content? Learning about good indexing practices on SQL server should also be helpful in dealing with a large influx of users.
Both but code improvement would be the first to target. Writing code that will scale will help you out the most. You can throw more servers at it behind the scenes but you would have to do this less with well architected code that was designed for scalability.
Depends on the technologies your using and how the code you write is written.
Since you tagged sql-server, when it comes to databases in general, you are limited by your locking strategies and your replication architecture a lot of the time. How you design your database and put it into production has big impact. Things that have to happen in any type of serial manner are bottlenecks. Check your execution plans, watch and manage your indexes, and replicate and distribute your systems if you can.
The best way to understand your scalability limitations is through load testing and proper QA.
If you don't do it right, your users are sure to be unhappy when you start 503ing or timing out. :-)
If the site is developed in such a fashion that you can have multiple servers/data access layers, then scalibilty should not be an issue.
Create the app so that you can loadshed as required, and keep the code as flexible as possible.
But from past experiance. Performance tune once it is required. Write easily understandable and maintainable code, and fix performance issues as the occur.
The best advice I can give is to test your app and server before you go live, then you can see when you are likely to get problems and how bad they could be.
It is one thing to say 'it will go slow' but once you get past a certain point your app may crash or randomly give users error 500 pages.
Test with automatic scripts tools to stress the site and simulate sign-ups and random users visiting random pages.
If you have SSL make sure your tools simulate lots of different SSL connections rather than just different HTTP requests ( SSL handshakes take extra resources )