Tag Info

New answers tagged

1

If you're going to have a significant amount of logic written client-side, then consider using MV[C]-style "separation of concerns" in your client-side JS code. For example, you might have some JS "view" logic which handles rendering: <script type="text/javascript"> function renderUser(user) { $('#username').val(user.username); ...


0

Unfortunately, there is no way to do cryptography securely in JavaScript. To summarize key points of the link: JavaScript has no secure random number generator and no secure key store, meaning it cannot securely generate or store encryption keys. There is no way to guarantee the browser itself is not compromised. Without SSL/TLS, there is no way to ...


2

There are a variety of places one can learn about such things. There are some book-style references you can read, but a lot of information takes the form of engineers and architects speaking and writing about their systems, and bits of wisdom they have learned along the way. Some systems are very straightforward, and follow established patterns. Others solve ...


1

Acceptance tests should be written first, before the code is written. When they pass, you know the feature is complete and does what it is supposed to do. However, most of these tests only follow the happy path. Let's consider two scenarios: Your QA department is able to handle writing their own automated tests. In this case, you've saved them the ...


1

This is fully up to the company or organization you are working in, so ask the persons who are responsible for defining the organizational structures. However, there are some rules of thumb which distribution of tasks will work better. For example, if your QA department consists of people with no programming knowledge, it won't make sense to give them the ...


2

I think you can look at a few options... Start by Building 2 Prototypes One prototype with all sounds pre-fetched. One prototype with all sounds available on click. This will allow you to actually compare if it's really that bad. Depending on how you architecture this, you probably won't need 2 separate prototype and just a configuration change ...


3

Identify and cost the shortcomings inherent to your existing development process as $A. Identify the cost of switching to any other development process as $B. If $A is less then $B, stop. If your known shortcomings outweigh the cost of change (and that is a big if!) then analyse the shortcomings in detail and start looking for a language/development ...


5

There are business reasons for choosing a language, and there are engineering reasons for choosing a language, and the twain do not always meet. Throwing in academic reasons is likely to make things worse. I doubt a professor will be able to help you in the way you need. The facts about a language's ancestry and features are pretty easy to find. You ...


49

@FrustratedWithFormsDesigner hinted at this above, I'll be more blunt: you've been charged with a expensive but useless task. I suspect the CEO is looking for irrefutable, objective evidence which will support his choice of language. The problem is that preference of language is loaded with far too many subjective and extrinsic factors for the white-paper ...


23

Some broad brush strokes to consider: Language popularity This really shouldn't matter, because popularity does not necessarily equate with productivity, expressiveness or any of the other language qualities that matter more, but this consideration often trumps all other considerations because: It's easier to find software developers in a popular ...


0

I have been develloping HTML/CSS with several designers and as already stated, there is no "silver bullet". The designers I have worked with didn't know much (nothing) about html/css. Some of them had some experience in webdesigning and I must say when they have that knowledge, it always ends up with easier to develop and "better website" especialy when ...


1

Since you have to do unit testing for the REST API, I would assume you are using mock objects for those, rather than interact directly with the database. This should give you a framework of proper "valid" responses from the API already - what I'm getting at is that when you test, you should know you're in "test mode" (either through some global environment ...


4

First of all, you shouldn't be testing against your production database. If you ever need to rerun your tests after the application has gone live (and you will need to do that), you run a serious risk of losing or corrupting data that is vital to the business. So, instead of testing against the production database, you test against a test database (which ...


0

Given HATEOAS, you only need to change the base URL for your RESTful service to point the UI service to another implementation of it. So set up a staging version of your UI and test it against a staging version of the data service, making that one change.


0

All other things being equal, I prefer not to use two different architectures in the same application, unless there's a good reason to do so (native handheld device support, for example). That said, your solution depends entirely on your requirements. If all the administrative UI does is set some values in the database, and it will never run outside your ...



Top 50 recent answers are included