|
popchecker wrote: I am working on a CSS parser ...
Before you re-invent the wheel, have you seen this project[^]?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
popchecker wrote: If But now I concern about the rising number of this statergy pattern implementations
10? 1000? 100,000?
popchecker wrote: Before analyzing the performace like aspects
I would expect that profiling would determine that implementation methodology of accessing the functionality would have zero impact (just noise) for either method The functionality represented by each and the usage to which each is put would be the problem. If there even is a problem.
|
|
|
|
|
Could any one help me in order to configure team foundation server on our local machine.
Thanks in advance.
|
|
|
|
|
Hi all,
is there a possibility to get the current caption bar colors (background of caption), the button colors in the caption (normal, highlight, click) and the frame around a window (active, inactive).
GetSysColor and afxGlobalData do not give me colors, which are equal to the one of the system.
Regards,
jung-kreidler
|
|
|
|
|
I've done things wrong, I confess, now I'm paying the consequences with an endless refactoring.
I'm trying to adpopt a new working paradigm.
I'll expose a concrete case, to make myself clear.
The application is about Recipes. User adds a new recipe, the application takes the information of that recipe and calculates the time it will take to cook it. Then the data is stored on a database, so you can read it again in the future.
Paradigm i've chosen so far:
1) Recipe: object to interact with the UI only has properties:
Public Class Recipe
Public Property Name
Public Property Ingredients as list(of Ingredient)
Public Property CookingWays as List(Of String)
End Class
2) Class to interact with the database
Public Class Persister
Public Sub Register(Rec as Recipe )
End sub
Public Function GetObject(Rec as Recipe, id as Long) as Recipe
Return Rec
End sub
End Class
3) A Class Factory. I call a method of this class inserting as parameter as string and get a new object.
Public Class Factory
Public Function Instatiate(Recipe as String)
Return New Recipe
End sub
Public Function Instatiate(Recipe as String, id As Long)
Dim rec as recipe = Instantiate("Recipe")
Persister.GetRecipe(rec, id)
End sub
End Class
4) Overload methods in the Validator Class and throw an exception if something isn t correct.
Public Class Validator
Public Sub Validate(Rec as Recipe)
End sub
Public Sub Validate(Ing as Ingredient)
End sub
End Class
5) FormManager: this class takes "objects" (like recipes or ingredients) and depending of what we want to (insert new, modify existing) shows the form
Public Class FormManager
Public Function Insert(Rec as Recipe) as Recipe
RecipeForm.Action = "Insert"
RecipeForm.Show()
Dim Val as new Validator
Val.Validate(RecipeForm.ObjectInUse)
Return RecipeForm.ObjectInUse
End sub
Public Sub Insert(Ing as Ingredient) as Recipe
IngredientForm.Action = "Insert"
IngredientForm.Show()
Dim Val as new Validator
Val.Validate(IngredientForm.ObjectInUse)
Return IngredientForm.ObjectInUse
End sub
End Class
6) RecipeManager: it will do te magic, uses all the other classes
Public Class RecipeManager
Public Function CreateRecipe As Integer
Dim fac as new Factory
Dim Rec = Fac.Instantiate("Recipe")
Dim f as new FormManager
rec = f.Insert(Rec)
If Rec is Nothing Then
Exit Function
Else
Dim per as new Persister
Per.Register(Rec)
End If
Return GetTime(Rec)
End Sub
Private Function GetTime(RecipeToAnalyse as Recipe) as Integer
End sub
End Class
Now analysing the Principles:
1) Single responsability: Okey. Every class do the thing they were made for.
2) Open Closed Principle: If I'd like to add functionality tomorrow, lets say I want to add a property to the recipe which is called ToolsNeeded. It tells you what knifes bowls or microwave you need to cook it. I could make new subclasess like:
New Class
-RecipeWithTools: Inherits Recipe and adds the property ToolsNeeded
I overload new methods to this classes:
-FormManager: Shows an extra textbox where you write the tools.
-Validator: Check object RecipeWithTools has value in the ToolsNeeded property.
-Factory: Instatiate(RecipeWithTools) and Instatiate(RecipeWithTools, id):
-Persister: adds method Register(RecipeWithTools, Select): Register(RecipeWithTools, Insert): Register(RecipeWithTools, Delete): Register(RecipeWithTools, Update)
Stays the same:
-RecipeManager: stays the same because nothing was changed in calculation function. The Create Method is called with "RecipeWithTools" String so the factory knows it has to return a RecipeWithTools. The form manager knows it must show the textBox for the ToolsNeeded. The validator knows it has to check if the objects has the ToolsNeeded.
3) Liskov Substituion: In the new derived classes i could use the Recipe class instead of the RecipeWithTools and everything would be the same.
4) Interface segregation principle: Not using interfaces here, I understand I replaced them with inheritance. ¿It's Okey?
5) Dependency inversion principle: Eh... No clue.
On the other hand I think i have three layers separated here:
UI: FormManager
Business Logic: Recipe, RecipeManager, Factory y Validator.
Data Layer: Persister
Questions:
1) What do you think of the model?
2) Should I use an interface if i think that in the future RecipeManager is going to work with objects that have common things with a Recipe, but are not a recipe? If not, when would that be?
3) Can anyone explain to me how would principle 4 and 5 apply here?
|
|
|
|
|
MarkosElCojudo wrote: 1) What do you think of the model? It has more documentation than usual. It also shows that you put an effort into your design decisions
MarkosElCojudo wrote: 2) Should I use an interface if i think that in the future RecipeManager is
going to work with objects that have common things with a Recipe, but are not a
recipe? If not, when would that be? A recipe for concrete, for instance; it is rather similar. Sand, water, cement, tweedeledeet, concrete
If the recipe-making is further expanded into a hierarchy of subtasks, you could put all kinds of generic procedures in there; ingredients can vary from resources to any raw material or tool.
MarkosElCojudo wrote: 4) Interface segregation principle: Not using interfaces here, I
understand I replaced them with inheritance. ¿It's Okey? If it works for you, then yes; oke is not 'ideal', but already a better starting point that lots. I'd still recommend programming against an interface; it would give you some more flexibility during maintenance, since anything that adheres to the interface would be permissive. Do read on, since..
MarkosElCojudo wrote: 5) Dependency inversion principle: Wikipedia[^] has an accessible description.
In short, instead of having one layer depend on the other, it merely depends on interfaces. If you do expect this project to grow into multiple recipe-type's, I'd certainly recommend it
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Really the key point of SOLID design is to properly abstract your objects. Signature and implementation should not be the same thing. There is a bit of code overhead involved, but when you find you need to scale an application you'll be grateful.
In that interest, generally you want to define interfaces and build your objects off of them. This way, if you need to add functionality later, you can build another interface to fulfill that requirement, add it to the appropriate objects, and act on that interface rather than on the objects themselves. This prevents changes from breaking functionality that worked before, and the spaghetti code that inevitably follows. Now, you can use an abstract class instead, but it's not as good a solution for exactly those reasons.That is also a large part of the point of the Interface Segregation principle, you can always add interfaces to a class and link functionality via those, rather than changing the current (working) signature. You can even add interfaces to interfaces if needs require.
The last principle, Dependency Inversion, carries the previous to its logical conclusion. Don't act on an object, act on an interface. If you need to cast something, cast it to an interface. No other class should care how an object performs a task, just that it performs it.
For instance, if I'm using a SQL server and want to switch to Mongo, my previous SqlRepository object will need to be swapped out in every place that I declared it in code with a MongoRepository. Even if I did a bulk REGEX replace on the name, potential second order effects are very likely. I might have a method or property in the SqlRepository that I didn't replicate, or that I didn't replicate with the exact same signature. This could easily break my application.
If instead I acted on IRepository, from which I implemented both SqlRepository and MongoRepository, I would not have to change any other thing in my application just because I swapped out the repository type, except, perhaps, the inject point. The interface would force me to match my signatures, and the expected input would generate the expected output. This way I add a class, change one single word in my dependency injection mechanism, and now my application uses a completely different data backend that is not even remotely compatible with the old one.
Now I know this isn't a bullet-point list of SOLID principles, but really that mnemonic is just a way to catalog all these ideas and hang a label on them. I hope it helps.
|
|
|
|
|
After suggestions for algorithms, products or anything else in the arena of high performance name matching.
Background - we allow our clients to upload a list of names to our systems, and then we screen those names against a list we hold on our side looking for matches. Ballpark figures are ~500K uploaded records being compared against >5M on our side.
We've currently got a couple of ways of doing this, from a Sql DB & Entity Framework (no giggling at the back), to a full on in-memory dictionary with all possible parts of every name broken out and indexed (I said no giggling).
I'm looking for high performance, high accuracy matching, and it would be nice if I could also do things like distance matching (probably using Levenstein), but the core matching needs to be as fast as possible.
I'm considering an in-memory Sql instance (not ideal), Apache Solr (not sure, never used it) etc and I was wondering if any of you had experience and could make some recommendations
C# has already designed away most of the tedium of C++.
|
|
|
|
|
Is Curaçao the same name as Curacao? Should the matching be case-dependent?
For an ASCII comparison, I'd compare ordinals; with the list partitioned by string-length.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Hi Eddie,
Thanks for the quick reply....
On the various types of match, we have some rules defined around things like aliases, diminutives etc, so we could express those in a rules engine, or if I have to code this up myself, then in the C# - completely agree that if I do end up doing it myself, ordinals etc are the way to go...
I'm not really after advice on the actual matching, more the sort of infrastructure I can put around it to make it as fast as possible...to be honest, if there's something "off the shelf" that would be ideal lol...
C# has already designed away most of the tedium of C++.
|
|
|
|
|
Depends on budget and hardware. If you can use multiple computers, then you would send your "name_to_check" to those PC's, and have them each check a part of the list.
Same principle can work on a single machine, using queue's and threads, but the fastest would be to use a *few* dedicated computers
--edit
Italic part added for clarification.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
modified 2-Sep-15 17:14pm.
|
|
|
|
|
A year ago I had a similar problem. We should save requests on a server and each request had an id Guid/UUID.
The solution turned out to be simple and fine. We simply wrote each cipher (in the guid) as a folder. That meant we got a folder hierarchy 32 deep with 16 branches on each level. Now one should think that it would have a terrible performance, but it actually was quite fast on linux with a solid state drive.
Another benefit was that maintenance e.g. backup was easy with this solution.
Maybe you could try something similar.
|
|
|
|
|
I know that I'm late to the party, but if you're just checking for the existence of the names why don't you run it against an in-memory hash array? Bootstrap it from your database and order it, then you should just have to hash the records and run a binary search with that. Rainbow tables can be used for good, as well as evil!
|
|
|
|
|
How to do Responsive Web Design Testing? 
|
|
|
|
|
Is it possible to apply CSS to half of a character/word?
|
|
|
|
|
You could use the HTML <span> tag to create a span consisting of the first part of the word, and another span consisting of the second part of the word.
Look up the <span> tag
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Hi, You should use tag for that particular word or character.
|
|
|
|
|
I am doing a project and the circuit is ready with me..
I just referred
http://www.instructables.com/id/Automated-Blood-Pressure-Cuff-Arduino-Project/?ALLSTEPS
where the programming code is given as a picture which is not clear
so I need the same programming code. please help in this
|
|
|
|
|
Then go back to the site and ask the author.
We are not here to provide technical support for other web sites!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
This is both a specific question about my quandary and a "philosophical" discussion about making a switch mid-project.
Background
I'm working on a project with lots of different UI "screens"/Windows, and it's getting ridiculous to open and close the windows, as the user moves to earlier "screens". I am however a month into the project, (a few hours every week, as this is a side-project), so I'm afraid I might have to re-design and re-code too much to do the switch. (I'm sorry to say that I haven't used pages before, so I know nothing of the time it would take).
The basic requirements
This is a customer tracking program for a car-wash facility. It needs first a login "screen", which either leads directly to the "user" landing "screen", or brings up options to either open the admin "screen" or the "user" "screen". Admin is just a single "screen", that has information about the users and options, nothing complex. the "user landing screen" is a "hub" leading to "screens" doing things like:
Adding new customers
Product search
Reserving a timeslot
Reporting incidents
Perform a transaction
Looking up costumer information
and more...
with every "screen", by necessity, having multiple it's own sub-"screens".
So far
At this point I have 7 windows, some that are on top of others, and some that replaces others. The actual code is divided around willy-nilly, (I'll have to do a clean-up before I'm releasing it). I have had some end-user tests, and it seems that it's a little bit confusing where to go, though I wasn't told that it was confusing. I had plenty of negative constructive feedback on other things, so I think they might be used to fumbling about, (Excel sheets was the previous "system" they had). However, I saw the fumbling about, and it irritated me, that I designed something that's inefficient.
The Quandary
Should I change it to a page-design or keep it as it is?
In general, should anybody change something like this in the middle of a project?
Please discuss, I'm not looking for some specific solution, but rather advice
|
|
|
|
|
In the OS we call Windows, we have "windows" to group functionality; each Windows-application will show you a main-form, sub forms and dialogs.
Pages comes from web-design, and it is good for things like books. A dialogue in a page is nonsense.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
But isn't this what modern UI design, (not to be confused with Modern UI), is going towards?
What would be the alternative to jumping around, opening and closing different windows?
And "Forms" are dead 
|
|
|
|
|
Frank R. Haugen wrote: But isn't this what modern UI design, (not to be confused with Modern UI), is
going towards? I wouldn't know, just being practical; they're different ways of communicating, and not all applications will lend to being presented in "book form".
Frank R. Haugen wrote: What would be the alternative to jumping around, opening and closing different
windows? Yup; although the jumping is limited - take the "new connection"-dialog from Sql Management Studio, it goes away if you hit enter. It doesn't require a complete page to open something new
Frank R. Haugen wrote: And "Forms" are dead Yeah, I heard that before
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Just a couple of thoughts off the top of head.
Your post reads as if you are not sure of all the requirements yet? You are just coding this up as you go? If you are running into problems about the User Interface and usability it is likely you are not sure enough of your problem area. I would expect you to start having other problems with the application in time. Especially if your requirements start shifting.
If you are using WPF then you should have been using MVVM. (Or MVC in Winforms). This should allow you to reorganize the screens without too much effort. If you are going to do it, now would be the time before you've any nasty deadlines to meet.
If your users are struggling with your UI, you have to respond to that otherwise they will just revert back to their old methods - the ubiquitous spreadsheet. Again, take a step back and review all their processes to get an idea of how you should structure the UI.
Get feedback by drawing diagrams of the screens you envisage, perhaps with annotations of validations etc. Then prototype the screens using mocking to provide dummy data. Then deliver the final thing. Something like that ...
|
|
|
|
|
Part of this mess is that I keep getting "oh, and could we get this feature"-messages. This all started as just a more "visual" way record information. Also the Excel approach lead to a few situations where a day's or week's worth of records were deleted, having a UI that is "layer 8 proof" is simple enough, tacking on a lot of "stuff", though simple in a website, in desktop development, it's maybe not more difficult, but it isn't the same thing.
I'm basically doing this as a favor, so time isn't critical. or I wouldn't be asking questions, but rather just make a messy program, and do an "update" after having re-done it in some other way.
Since my field of expertise is mostly web-related, the methodology of desktop application development isn't something I've really studied. And so MVVM isn't something I've seen as anything more than the separation of the UI dev team and back-end functionality dev team, and therefore not something a single programmer should focus on, (I might have to spend some time on the Microsoft Virtual Academy or similar).
I have been trying to get feedback on sample layouts and I've requested drawings of what they envision, but it is kinda like that The Outmeal comic about web-design: How a web design goes to hell.
I think I'll redo it all, and make it more MVVM, or at least move everything away from the "code behind", so I make it usable regardless of how I do the UI in the end.
|
|
|
|
|