|
I suggested a "client" (NOT web) application: console; Windows forms; WPF; service; Java whatever. Something more manageable and flexible than a "web app".
If you want to know more about how "servers talk to clients", refer to "asynchronous callbacks".
You've already established a work-flow; all you're trying to do is introduce a retry mechanism. Step back and think about this "client" as a "monitor" / observer that submits retry requests; that's all.
|
|
|
|
|
I think I understand. The application does have a main entry point and there I can start a separate thread to handle the observation of the primary web services output.
|
|
|
|
|
Yes; start small. Just query the server every 30 seconds at first (send a web request; the server responds) as a proof-of-concept. Once that mechanism is working, introduce a new request to "retry", etc.
|
|
|
|
|
Thanks! Once I get something working I will post the code back to see if everyone agrees with my design.
|
|
|
|
|
We have a php project (made in core php and mysql), now i am willing to scale it and would like to go for SOA. I am thinking of a service layer with WCF and calling those services from my PHP code. What would be the best way to move further? Is it the right way i am thinking or any other way should i consider?
Thanks,
PS:We are developing a product and started with core PHP due to resource shortage, Please suggest me a way so that we can design APIs and reusable components consumable by any client.
|
|
|
|
|
Not exactly sure what you think you are asking but if you are attempting to design a system to meet business needs...
First it doesn't have anything to do with specific technologies.
Second the FIRST thing that is needed is realistic business expectations as to what the business actually needs.
Finally, most business realistic needs do not require anything at all in terms of scaling with modern environments.
|
|
|
|
|
I'm developing a C# desktop app which runs on Windows, Mac and Linux (under .NET or Mono).
The plan is for the program to be divided into two parts in separate processes: The front end GUI and the back end storage server.
The reason for dividing roles in this manner is to facilitate access to the data store by indexing services. The data store can be indexed by the operating system regardless of whether or not the front end GUI is running.
So, my question is: What technique do you think I should use for inter-process communications between the front end and the back end? HTTP-based REST is feasible but how fast is it in practice? I need something fast and cross-platform compatible. Any suggestions?
|
|
|
|
|
markrlondon wrote: The front end GUI ...I need something fast
Exactly how fast are the humans that use that?
For a desktop app that has, for example, 100,000 simultaneous users to the same back end, I suspect you are going to run into other problems.
markrlondon wrote: HTTP-based REST is feasible but how fast is it in practice
Versus what? Everything is basically IP these days. And unless there is something really wrong with your network even establishing a connection takes too little time for a human to care.
So unless you have some actual real (and realistic) business metrics that are very large then use whatever you already know. Because doing that will mean less delivery time of the product and that is much more likely to be what the business cares about.
|
|
|
|
|
Thanks for the reply.
Just catching up here...
|
|
|
|
|
.NET and Mono are not the same beast; you'll find that there are subtle differences in implementation.
Fast inter-proces communication can be achieved by writing to shared memory.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
Hello everyone. I want to create web service for mobile game. Can anyone say about his experience and may recommend some principals, arhitecture., service.
Thank you
|
|
|
|
|
I am the senior engineer at my firm and I have been asked to outsource some of our projects. After much deliberation, we had two projects done this way.
Here is the question... my team and I reviewed the solutions and found a pattern that we could not understand... here is one example:
The ASP.NET application contained a few work steps where an email was to be sent. There were a total of 13 different instances. Each instance had code to read the app.config settings, set the mail properties and send the email. A new SMTP server required SSL and we had to update all 13 instances.
SO... why would the developers code this 13 times, instead of writing a simple static method/function???
We took the solution apart and found this "pattern" all over the place.. lots of cut/paste, hard coded values, etc... I am missing something? Is this something we have to get used to when dealing with outsourcing?
I know.. lots of questions.. but some insight would be appreciated... thanks.
LM
|
|
|
|
|
Lucas A. Martinez wrote: Is this something we have to get used to when dealing with outsourcing
Yes!
Think about their business model, they make money from churning out solutions and the hours spent supporting the solutions. So the faster the solution and the more intensive the support the more money they make!
Where is the incentive to write elegant, supportable code? It always astonishes me when an organisation outsources their development and then expects quality.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Next time, give them a small job for a fixed bid that you can review at the end of the week.
If they "fail", they don't get paid or hired. Get it in writing.
(In the freelance "business", "fixed bids" typically don't get paid if you botch the job).
Another thing: the person you interview is not always the one that winds up doing the job ... You can be as skilled as you want interviewing, but in the end, they may very well just pass your project on to some code factory (because you can't see them).
And all the while you're thinking: "But they sounded like they knew what they were doing...".
And of course they did.
Anyway, outsourced or not, there should be some deliverable to review at the end of each week so you can catch issues like the one above.
I assume the project manager / lead was "theirs"?
No?
|
|
|
|
|
It probably would be best to review the code yourself and make no compromises.
Unfortunately, I am one of "them" and have seen stuff that would probably make any sane programmer want to shoot him(her)self, but I have also seen that the above method works. I would recommend trying that, if possible.
|
|
|
|
|
Hello:
I need to build a reporting tool that can read an xml file (which is the data output of a piece of hardware). The report would be populated with the read-only data (output from the hardware), but there also needs to be a comment field added to the report template that the user can data enter into and then the whole thing needs to be saved as a filled in report instance. I was thinking .pdf.
1) One way I see this application is.: I would create an xsl file for the template. The xsl file would be merged with the xml file to create the report.
The data is sensitive so I don't want the data in the cloud.
It will be available locally via a flash drive.
If I did it this way, I envision a local web server to be started on the client since a browser can not read a local xsl or xml file without security issues.
So, this design is kind of a local web application.
2) Another way is to create a desktop application, but then there are distribution issues and runtime issues, if it's a C# application. The other alternative for me is a Java Web Start application.
Either way, I do it, I think it would be easiest to have the data/template be displayed on the screen so the user can enter the comments into a field and then have another tool save to a .pdf.
Any ideas or has someone done something similar where they would be able to share what worked for them?
Dan
|
|
|
|
|
Just create a PDF with a comment field the user can edit. The user can then add a comment and write-protect the PDF / comment field if they want to.
(Later on you can start getting "fancy").
|
|
|
|
|
Background
In my workplace there is a debate on two backward Compatibility (BC) implementation approaches. I am not talking on the question if our code need to be BC, this is given and a consensus. The question is how to do it in the code level.
Lets assume that we have CodeA with inputA and resultsA and newer evolved code CodeB.
The Code, of course, knows to identify if the input is A or B.
Lets assume that ~20% of the code functionality was changed.
Lets assume that each version footprint is 1Mb.
The BC requirement is that CodeB with InputA will provide ResultsA.
Strategy 1 – if in the top + code duplication
One approach which is led by the more agile side says:
When I evolve my code from A to B, I don't want to think about BC. I will do it as if this was the very first (ever) code. Then in the last stage I will wrap both CodeA and CodeB by a switcher in the most higher level that will call the full old codeA when he sees InputA. I know it is code duplication but binary size is no concern these days and my newest code is always clean and not carry the old deprecated code. When code A will not be necessary anymore few years from now I will throw it away and will be left with B (or C, D ...). I know this is not elegant but time to market is more important and again even if I have 10 versions together it is only 10Mb.
Strategy 2 – if in the fine grained bottom level
Second approach which is led by the more classical "by the book" SW engineering says:
When I evolve my code from A to B I will put a BC handling (if or whatever) on the fine grain lower level changed functionality (functions, methods, lines …). After all it is just 20%. I know it is tiresome and my one code will be with ugly BC handling on many lines but I have at least one consistent and compact code and not huge code with A,B,C,D,E full versions inside.
What do you think? Who is right? Will be happy to hear why, cons and pros + ref to reading on this subject.
|
|
|
|
|
Approach 1 is not DRY, and would require maintaining similar code. Meaning any update will have to be done in multiple places, creating multiple places to fail and test. If you make it a strategy, you'll get a large codebase with duplicated functionality. Will become hard to maintain over the years.
Make it SOLID.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy, Thanks for the comment.
However, Guy#1 will say. I am DRY! I am only updating the latest version. In a matter of fact I will never refactor the older code because I want it to work EXACTLY!! like it did when it was the most updated. This is "rollback by design".
proper disclosure - I belong to the second group but want to challenge what I've been told and "raised on".
|
|
|
|
|
Lior Cohen wrote: I am only updating the latest version
That may be the idea, but sooner or later there is a change that needs to be in both versions. If you have a duplicate, it is not DRY.
Lior Cohen wrote: In a matter of fact I will never refactor the older code
Even if you never refactor, never change requirements, if there's a bug that needs fixing that gets discovered later, you'd be fixing minimal two places.
Don't tell me it won't happen, it happens continuously.
Lior Cohen wrote: This is "rollback by design".
No, it is being incompatible with your older version.
Good compatibility means, among others, that data-files can be used by both versions. Meaning the older version will need to ignore extra data and the newer version needs to check whether it is there before acting on it. If your new version uses a new layout and converts all, then you might no longer be able to "rollback by design" without destroying the users' data.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: you'd be fixing minimal two places.
I think i need to describe my system a little, as I don't understand why you claim I need to fix a bug in both places.
My code is an image processing module (no UI).
The input is an image and a parameters bundle we call a "recipe".
one of the recipe parameters is the version of this recipe.
The recipe is created from the same context so it always created with the version of its creator.
In pseudo code is
out = process(in, recipe)
Approach 1 implementation will be like this:
out = process(in, recipe) {
if recipe is of version Jan {out=process_Jan(in, recipe)}
else {out=process_Feb(in, recipe)}
}
Now suppose there is a bug on process_Jan (the old). Fixing the bug will change the results anyway so the customer had 2 options
1. Stay with the Jan version including the bug (bug compatibility  )
or
2. Move to a new March version with bug fix but with different results.
The bug fix will be change the code like this
out = process(in, recipe) {
if recipe is of version Jan {out=process_Jan(in, recipe)}
else if recipe is of version Feb {out=process_Feb(in, recipe)}
else {out=process_Mar(in, recipe)}
}
so here I changed the bug only on Mar and not in all places.
Please try to explain on this example.
modified 10-Oct-15 10:05am.
|
|
|
|
|
Lior Cohen wrote: Please try to explain on this example.
That's a nice little example which is severely limited in scope. As you can see, 'proces_A' is not named after februari (what year?), so it may already be confusing to the casual reader.
Sh*t starts happening once there is a dependent method; imagine calling "DoSomethingWithImage" from process_Jan. It needs a bugfix too. Now all methods using that will need to be changed; one path to guarantee the old behaviour, one for the new functionality.
I'd recommend using inheritance, not a bunch of if-switches.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
The vendors I currently work with have a very simple versioning policy:
If you want support and a fix for a previous version, you first need to upgrade to the latest version (for free). The upgrade is a no-brainer; in some cases done automatically. (A version# is what kicks anything off if it does not match what is currently available online).
(If you want to be cagey, call the upgrade a "fix"; who's to say when a fix becomes an upgrade).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
