Can someone explain in detail with a simple test program on what is mean by Delegate, Events separately and then explain on how both are inter related to each other? I learned in many books but not feeling comfortable with topics as of now. Any reference videos are also fine.
Related
I would like to ask you about your opinion and what you see as cons and pros to use ElasticSearch as EventStore.
I would like to hear if somebody had experience with using ElasticSearch as event store and what was the results, reliability and if there was any issues.
eta: Reminded of this post by a no-explanation-down-voter... This Kafka is not for Event Sourcing post is pretty useful when thinking through this sort of a question.
Elastic search is simply not designed to be an authoritative persistent store for actual app state.
Neither is Redis.
Neither is Kafka.
All three may potentially be useful in the context of an app which does employ an event store.
May I suggest reading a book like NoSql distilled to get an idea of selection criteria in this space so you'll know how to select something appropriate.
Also for a question like this to be more answerable (in general questions like this are considered subjective and get closed), it's important to supply context as to what sort of stuff you're going to maintain, what sort of access patterns, what sort of scale and/or any other context. A laundrly list of contextless pro/cons is not going to help much.
Several months ago I met a flux and I found it's awesome, I love it, I use it.. almost in every new project and when I met a redux I love it even more, but couple of days ago Pete Hunt publish a tweet where he judge the people to use flux for everything. And I think it have a perfect sense, but on the other hand I don't get it.. He publish another tweet where explain cases for flux, also I read an article about use cases for flux. Long story short - "If your app doesn’t have complex data changes and caching, don’t use it. But if it does, I strongly recommend you try Flux." and it's totally make sense for me why I should use flux, but it not clear to me why I shouldn't if I don't have a complex data changes.
In the article Dan point, that when you faced those issues(that flux solve) in real project you can easier to understands the benefits of the flux, but exactly of this(cause I faced with these problems at work project) now I try to use flux in every project, because I don't wanna to deal with it anymore.
And crazy part, that now I often use it also for ui states, not just data changes. Let's pretend I can have a widget component, for example a clock. It can make some ui changes, like show/hide seconds, switch between digital/analog and it has a daytime type state(day/night) and can dispatch an event when it changed, but other component listen it and can react, for example change a background color. I can easily solve it just with local component state and container(smart component) state, but same as I can put all these logic into store(reducers) and components will be really dump and just react on the current state(props) and containers(smart) just listen the store and partitioned state between the components. And if even it looks ok, point that I can use it for every ui state - open/close sidebar, some specific component changes, etc.
Reasons why I can do it:
It looks predictable for me. I completely know that any changes happened in my app serve in one place.
It easy to debug. I can just log all the actions and if I will get some bug, I can easily found what happened and reproduce it.
I can easily expand my app without worrying, mb I should move something to the flux state, cause I already did it.
But also I agree that it's looks overwhelmed and I can solve it without flux, but I can't answer to me, why I shouldn't use flux in these cases. What is wrong with it? Please help me.
I was wondering about the best practice when using the MVC pattern.
When you develop an app for a client, you want to think business. You want to think as the customer would. That's why I'm wondering :
Isn't it better to develop the view part, without any data treatment, so the customer can validate it ?
I see this practice as powerful as TDD is, I mean if you clearly know what your program will look like, you know which treatment it will require, making the model part a bit more concrete and business oriented, instead of making it too abstract and global.
I can not see downsides to this, so if you can see some, or explain me why it's not a good idea, please do.
Thanks :-)
The main benefit, as I see it, would be the ability to provide the client with hands-on prototype.
It not uncommon for clients to change their mind, because often, when they hire a developer or company, they actually have only a vague goal for the end product. This way you would mitigate the risk of large scale changes late in the projects life-cycle.
As for implementation of such approach, I would recommend for you to look into concept of "presentation objects" (Fowler has this annoying habit of slapping "model" on every damned term).
With presentation objects you would gain an ability to "shim" the data from model layer's services. And it also would let you figure out, what exactly services (and service calls) will you *UI layer( interact with).
Note: of course I am assuming that with "MVC" you do not mean some Rails-style abomination, where "views" are just dumb templates.
My question has two parts:
Does anyone have any tips or references to some documentation on the web about how to write GUI code that is easy to read, write, and maintain?
Example.
I find that the more extensive my GUI forms become, I end up with a long list of fairly short event handler methods. If I try to add any private helper methods, they just get lost in the shuffle, and I constantly have to scroll around the page to follow a single line of thought.
How can I easily manage settings across the application?
Example.
If the user selects a new item in a drop-down list, I might need to enable some components on the GUI, update an app config file, and store the new value in a local variable for later. I usually opt to not create event handlers for all the settings (see above), and end up with methods like "LoadGUISettings" and "SaveGUISettings", but then I end up calling these methods all over my code, and it runs through a lot of code just to update very few, if any, actual changes.
Thanks!
Some guidelines for the first question, from an OO perspective:
Break up large classes into smaller ones. Does that panel have a bunch of fairly modular subpanels? Make a smaller class for each subpanel, then have another, higher-level class put them all together.
Reduce duplication. Do you have two trees that share functionality? Make a superclass! Are all of your event handlers doing something similar? Create a method that they all call!
Second question. I see two ways of doing this:
Listeners. If many components should respond to a change that occured in one component, have that component fire an event.
Global variables. If many components are reading and writing the same data, make it global (however you do that in your chosen language). For extra usefulness, combine the two approaches and let components listen for changes in the global data object.
If you're using WPF, you might want to read the Composite Application Guideance for WPF.
It discusses many of these topics (as well as many others). The main goal of that guideance is to make large scale applications in a flexible, maintainable manner.
You should definitely look at Jeremy Miller's guide to rich client design. It is incomplete, but I believe he is writing a book on the subject.
Another blog you should check out is Rich Newman's. He is writing about Composite Application Block which is a MS best practice guide on how to structure rich clients.
You can also read this book which is only a very light read but gives you some good ideas.
I'm starting a project which I think would benefit from bindings (I've got a source list table, several browser views, etc), but I think it would also be quite doable, and perhaps more understandable, without them. From my limited experience I've found bindings to be difficult to troubleshoot and very "magic" (e.g. it's difficult to insert logging anywhere to figure out where stuff is breaking, everything either works or it doesn't).
Is this just my inexperience talking (in which case I could sit down and spend some time just working on my understanding of bindings and expect things to start becoming clearer/easier) or would I be better off just writing all the glue code myself in a manner which I was sure I could understand and troubleshoot.
Use Bindings.
Note that you must follow the MVC pattern to get the most from bindings. This is easier than it seems, as Cocoa does almost everything for you nowadays:
View: NSView and subclasses (of course), NSCell and subclasses, NSWindow and subclasses
Controller: NSController and subclasses (especially NSArrayController)
Model: Core Data
If you're not going to use Core Data, then you get to roll your own model objects, but this is easy. Most of these objects' methods will be simple accessors, which you can just #synthesize if you're targeting Leopard.
You usually can't get away with not writing any code, but Bindings can enable you to write very little code.
Recommended reading:
Key-Value Coding (KVC) Programming Guide
Key-Value Observing (KVO) Programming Guide
Model Object Implementation Guide
KVC Accessor Methods (part of the aforementioned KVC Programming Guide) and my complete list of KVC-compliant accessor selector formats
Bindings can seem magical in nature. To understand the magic behind bindings, I think one must understand KVC/KVO thoroughly. I really do mean thoroughly.
However, in my case (new to Obj-C -- 9 months), once I got KVC/KVO bindings was a thrill. It has significantly reduced my glue code and made my life significantly easier. Debugging bindings became a case of making sure my key-value changes were observable. I find that I am able to spend more time writing what my app is supposed to do rather than making sure the view reflects the data.
I do agree though that bindings is highly intimidating at first.
My general approach is to start out as much as possible using bindings and see how things go. However, if a particular interface element start to become problematic using bindings, or more effort than it's worth, then I don't hesitate to fall back to using more traditional methods (e.g. data sources, actions) when it makes sense. I've found these things can be pretty hard to predict ahead of time, but I think favoring bindings is better in the long run, as long as you don't get too dogmatic about sticking with them in situations when they don't provide any benefit.
After a while of working with Bindings I've found that it's not magic at all, thought it is sufficiently advanced technology. Debugging a bound interface takes different techniques than a glued interface, but once you have those techniques, the advantages in terms of reuse, maintainability and consistency are IMO significant.
It seems like I use bindings, KVO and data source methods all about equally in my applications. It really depends on the context. For example, in one of my projects I use bindings just about everywhere except the main window's outline view, which is complex enough that I wouldn't want to even try to fit it into an NSTreeController. At the same time I also use KVO to reload UI objects and track dependancies in my model objects.
The important thing to keep in mind when learning advanced Cocoa topics like Bindings or Core Data is that you must understand all the technologies behind them; everything from data source protocols, notifications KVO, and so one. Once you've had enough experience working with them to know how the "magic" works, you'll be able to integrate the higher level stuff into your application with ease.
In your particular case, you'll have to decide if it's worth the extra time to learn bindings on top of developing your application. If possible, it might benefit you to develop a simplified prototype of your application using bindings, so you know how to best fit the pieces together when you start the actual project.
My opinion is that yes, you should adopt bindings; the technology is well-understood and stable now, and it's worth doing for the amount of code you no longer need to write. When I first switched to bindings, I had quite a bit of trouble with getting the lifetime of observing and observed objects to match up, and with UI breakages because it was observing a valid object, but the incorrect one. Once you've seen those problems a couple of times, knowing how to avoid them and how to spot them if they do appear becomes straightforward. Ish. I still wish for "this event here caused this update here" traces in the debugger, but I'm still glad I made the move.
For the curious, I did end up using bindings and after a couple of days they suddenly just started "making sense". So I would definitely recommend just going ahead and taking the time to learn them.
I also found the advice of Brian Webster quite helpful, as I did indeed end up doing a handful of things the old fashioned way either because bindings couldn't do what I wanted or because it would have been prohibitively complicated to do what I needed using bindings.