This is the question asked in interview.Please reply to this question.
I have no idea about web services.Please reply to this question why do we test webservices on different end points.Please make sure I need an answer in your own words.
Tsk tsk, if you don't know the answer to an interview question it's better off being honest and just saying that you don't know, because if I was interviewing you I'm sure I'd pick up if you don't know what you're talking about...
However for the sake of your own education: let's say we have an endpoint
test.com/api/create
although this is one endpoint, you can say there are several which can be reached with different protocols. (Think http verbs - GET, POST, PUT, PATCH...)
You probably don't want someone hitting the create endpoint with a GET protocol but only POST.
Theoretically you can test for this, but if you're going out of your way to test for these kind of things, I'd start to think you were just wasting company time rather than really testing meaningful functionality lol.
-- In many languages you define the protocol you want an endpoint to expose
Oh and be sure to mark whatever answer you use in the interview as answered ;-)
Related
People have been saying that JForum is easily customizable, and lots of other things in favor of JForum. Through this question, I want to know from those who have used both Jforum and phpbb, that how easy or difficult is customization of the forum in both of these.
For example, say you want to change the theme/template. In my experience I found it much easier to change theme in phpbb ( but still haven't found a way to change the theme in JForum).
Please also suggest some resources where I can find some support for JForum, I couldn't find any support/documentation and so I'm still confused whether to switch to phpbb even if the client prefers Java?
To put this question another way, is there any reason why someone should use JForum when phpBB is available? (I hope it's not the same thing as Java vs Php)
Ok, 1 month and no answer! Looks like this question is not much important, perhaps because there aren't many who have used JForum and phpbb both.
After going through both of them, I eventually decided to go with phpbb given the customization possible, so my vote is towards phpbb. Opinions on this question are still welcome.
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 7 years ago.
Improve this question
We have a custom license check method, which is very simple, we just check a registry key(a string, set by another process based on different parameters) and grant license or reject.
I came to know that, anybody can simply crack this, once they get to know which regkey we are looking for. Or by searching for cmp instruction in assembly code.
I just wanted to know better solution for this license check problem. I may not need very complex procedure or any such. But if it should be little better than current one.
I use C++\VC++ with windows 7.
Thanks & Rgds, calvin
The only way to totally prevent cracking is to use a pay as you go based hosted application accessed by users remotely.
That way someone without a valid paid account can not use the application, and anyone handing his account credentials to other will pay for their use as well as his own.
No code (except possibly a stub to allow logging in) is ever sent to the client, let alone stored there, so the client can't ever operate without connecting to your server (which will hopefully not get compromised, but that's a sysop problem, not a coding problem).
Any other system you may adopt will essentially have to rely on the legal clout behind your license to deter people from cracking it.
You need to somehow protect your code against reverse engineering; there are many so-called executable file protectors and I will not name it here. Regardless of what you calculate, just two NOP instructions will push the flow of the protection check in undesired direction.
Of course, it really matters what kind of code you are protecting; for interpreted languages it is almost impossible to protect yourself.
Ah, sorry, I can name one, non-commercial: infamous Yoda's PE Protector.
You could calculate a hash from a hardware-specific value and check for that value in the registry. This way it wouldn't be enough to find which value you are looking for, but also the algorithm.
A mathematically sound way of doing this is would be to turn the computer-specific value (e.g. MAC address) into a prime number, multiply it with your own magic prime number and store the product.
Edit: Note, though, that it usually is not worth bothering with any protection scheme except very simple ones. Even large corporations are struggling with this problem.
Any logic running locally will always be prone to circumvention. With regard to the actual storage of a license depending on your application I would write a web service and run your own server. Get the app to check with your service each time it starts that the license is still valid.
This also gives you much more flexibility for example you could revoke a licence if payment doesn't clear.
You can accomplish this using public/private key encryption. Have local signed file instead of the registry that contains information about the license and having a web server to check the license is valid once in while. This should give you enough protection.
This can be done with LicenseSpot. On the site there's sample code, although only in c#.
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 6 years ago.
Improve this question
I'm a .NET web developer for a small organization. We have some skilled developers here, but what we don't have is anyone who's worked for larger, more organized, software shops. We do all right, but I find myself wanting to structure my code better with little place to turn for advice.
It comes to this. At some point someone in our organization decided we were going to use webservices whenever we had to do any data access at all no matter the case. Thus, our hardware architecture is organized so that is the only way we can access our databases. This sounds fine in theory, but the problem is most of our apps turn out like this:
Spaghetti Mess Of Code In The aspx.cs -> Web Service That Does Nothing But Call a Stored Procedure
Beyond that there's not much separation. Whenever I start trying to research better structural practices I wind up reading about things like dependency injections, dirty properties, and class factories, my head starts to swim, and I move on to something else in frustration.
Here's a basic example of my wonderings. So let's say I have to make a page to select employees from a list, edit them, and update the database. Is it better to have the web service return an Employee object on a get, and accept an Employee object on an update? Or is it better to have the Employee object call the webservice to self populate?
In other words: Employee emp = svc.GetEmployee(42); vs Employee emp = new Employee(42);
The second example seems like it would be better organization for updates (update the relevant properties and call emp.Update()), but the problem is what if I need to get a list of Employees? It would be inconsistent to do Employee emp = new Employee(id); for a singular employee, but do svc.GetAllEmployees() for a list.
I feel like I'm rambling a bit so I'm going to cease trying to explain and hope someone understands my confusion. I appreciate any advice that anyone can offer. Thanks!
As with anything, there are a number of different approaches you can take. (So hopefully there will be a number of good and different answers here, because this is definitely an important question.)
One question you should probably ask yourself about your design is "how much logic will need to be shared between applications?" Going with the small GetEmployee example you gave, it sounds like you want to know where to put the models in your domain. Are these models used by multiple applications? Is business logic shared across applications?
If so then you may want your domain models behind the web service. Maybe build up a rich domain behind those services with its data access and external dependencies (remember that dependency injection thing, the best design decisions will need to be in the domain behind the service layer since that's the core of the whole system).
Then, of course, how do you access this logic? Again, there are a lot of options. My personal favorite design is to have a kind of request/response system that abstracts the service layer. Something as cool as NServiceBus for a really disconnected asynchronous system, something as simple as Agatha for just abstracting out the actual service and putting the request/response logic in code, or maybe play around with ServiceStack (something I've been meaning to do) or another project, etc. Hell, you could just roll a plain old WCF or even SOAP service layer and nothing more. It's up to you.
At that point you're looking at a fairly procedural system at the service layer. This isn't a terrible thing. Think of the service layer like an MVC site. You send it a request, populated with some kind of incoming viewmodel, it does its domain stuff in all its object-oriented goodness, and returns a view in the form of some XML representation of an outgoing viewmodel. Now you have a repeating pattern. Your client-side applications are just great big views for your domain. The dumber they are, the more interchangeable and replaceable they are, the better.
This allows you to encapsulate various "business actions" in a unit of work at the service boundary. Given a request from a client application, either the whole thing succeeds or the whole thing fails. Wrap it up in good error handling and an application-level error/exception logger to give you all the details of the failed requests. (Imagine that every request can be serialized to a string and included in an error message. Now you have everything you need to recreate the error in a simple string, as opposed to asking users "what did you click on?" to try to recreate errors.)
If, instead, the back-end doesn't really share anything with different applications and each application is its own distinct entity entirely. At that point you don't really need to share all that logic behind the service layer, and it's entirely possible that you shouldn't try to make any kind of overlap. Is the data access the only thing that's behind the service? What about things like filesystem access or external web service access?
If the only thing behind the service is the data access, then you can keep your models and data access repositories in your client applications like you seem to be accustomed to and just swap out your repository implementations with implementations that internally reference and access the service layer. (This would be the second option in your GetEmployee example.) Properly abstracted, direct access vs. service access repositories can be swapped out trivially depending on where the application needs to live.
Of course, this leans a little towards a true persistence-ignorance approach, which can be dangerous. Performance implications need to be considered. Some piece of logic or unit of work on the back-end may hit the database several times to do several things. If this is happening across a service then that adds service overhead to each database call. So you'll want to address this on a case-by-case basis.
I guess I may be rambling at this point, so to get back to something concrete it really comes down asking yourself some questions about your domain. How persistence-ignorant can you afford to be? Do your applications share business domain logic? Do you need to access other non-database external dependencies behind the service only? There's no universal design that's always the right answer. You'll probably end up experimenting with various designs and homogenizing on a design that's right for your developers and your environment.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 13 years ago.
Improve this question
I am a technical team leader of a small programming team, working on a project for an external client.
I was recently asked to produce written evaluations of my team members. I feel uncomfortable doing this, because I don't see myself as a management person and never thought of my colleagues much deeper than "A is reliable and B is a lazy bum".
But I am expected to produce more elaborate stuff to be read by actual managers, and my manager hinted that the purpose of this is rather to test my evaluation skills.
Any hints or resources on how to produce a quality evaluation? Are there standardized forms? How should I address this?
Thank you.
I have found that Joel's Professional Development Ladder and this construx site provided great advice on how to start. It helps to understand the various knowledge areas and what developers are expected to know and do. You can then evaluate developers on how competent they are in various knowledge areas and assign them a level accordingly.
You of course have to evaluate their work ethic and attitude etc which have nothing to do with development as such.
First thing, don't be intimidated by the task. Second, you are a team lead, so your opinion of the people counts; it may be a test, but you should be up to it. Third, if you were doing this informally over a coffee and your boss asked you about someone you would probably have no trouble chatting for a few minutes about your observations of them and what you thought were their strengths and weaknesses. That's what you should write down in your review notes.
Ask your boss if there is a standard format - if you are in a large organisation HR might have forms and/or systems in place for these sorts of reviews. Otherwise, just give him a paragraph or two in plain English (or your language of choice) on what you think.
You can add colour to your reports by citing work they have done and where they have succeeded or failed.
Some golden rules...
don't get personal
try and be objective and fair
don't hide the truth, however uncomfortable
Good luck, it's all part of stepping up to be a manager and is fun in a way - your opinion is counting.
Tough question! I would suggest you first look back at evaluations that have been performed by your manager on YOU. This is usually a good example of what you are expected to produce for your team mates. If you have not had any formal evaluation yet, I suggest you look to your HR department, or management for a copy of a standard template for such purposes. Most large companies have them.
Evaluating team members can be tricky, especially as a team leader and not a 'front line' manager. Remember the following,
Be honest, with them and yourself
Evaluate based on performance not gut feeling, or emotion
Never ever evaluate someone better simply because you 'like' them or have empathy for their situation. It always comes back to you in the end.
Edit:
Some further things I thought of, been awhile since I did evals as a team lead..
When evaluating performance, look at not only what the person needs to improve, but also what they have done well. Try to present both sides of the story (even if you feel the person is a lazy bum)
Look at quantifiable results.. what has the person PRODUCED and how useful was it to the team as a whole. Remember, even if they pump out thousands of lines of code, that doesn't mean it was all useful, maintainable or even worth the time.
Good luck!
You could conduct a 360 degree feedback with your team (http://en.wikipedia.org/wiki/360-degree_feedback), motivating each team member to give feedback to his colleagues (and you).
Our whole system is being designed around REST and are now considering how processes which are quite clearly RPC in intent can be mapped to RESTful resources without using verbs in the URL. Our remote procedure call is used to rebuild our search index when a content listing has been modified elsewhere.
What we are thinking about doing is this:
POST /index_updates
<indexUpdate><contentId>123</contentId></indexUpdate>
Nothing wrong with that in itself, but the smell is this resource which has been created does not return the URL of the newly created resource e.g. /index_updates/1234 which we can then access with a GET.
The indexing engine we are using does have a log mechanism, so in theory we could return a URL to a index_update resource so as to allow a GET to retrieve the resource, but to be honest we're not interested in the resource as this is nothing more than an RPC in disguise.
So my question is whether RESTfulness is expressed in structure or intent. I feel the structure of what I have outlined is restful, but the intent is not.
Does anyone have an comments or advice?
Thanks,
Chris
Use the right tool for the job. In this case, it definitely seems like the right tool is a pure remote procedure call, and there's no reason to pretend it's REST.
One reason you might return a new resource identifier from your POST /index_updates call is to monitor the status of the operation.
POST /index_updates
<contentId>123</contentId>
201 Created
Location: /index_updates/a9283b734e
GET /index_jobs/a9283b734e
<index_update><percent_complete>89</percent_complete></index_update>
This is obviously a subjective field, but GET PUT POST DELETE is a rich enough vocabulary to describe anything. And when I go to non-English-speaking Asian countries I just point and they know what I mean since I don't speak the language... but it's hard to really get into a nice conversation with someone...
It's not a bad idea to disguise RPC as REST, since that's the whole exercise. Personally, I think SOAP has been bashed and hated while in fact it has many strengths (and with HTTP compression, HTTP/SSL, and cookies, many more strengths)... and your app is really exposing methods for the client to call. Why would you want to translate that to REST? I've never been convinced. SOAP lets you use a language that we know and love, that of the programming interface.
But to answer your question, is it a bad idea to disguise RPC as REST? No. Disguising RPC as REST and translating to the four basic operations is what the thing is about. Whether you think that's cool or not is a different story.