|
Given the recent controversy around the design of Windows 8, it’s interesting that Jensen Harris, one of the people behind the Windows 8 design recently spoke at UX Week, and that his presentation is available online for all to watch. If you’re concerned about this topic, you’ll want to check it out.... His central argument is that while each Windows revision has been familiar to users since Windows 95, people are willing to change if you give them something better. Resting on familiar is the way to mediocrity.
|
|
|
|
|
I, like so many thousands of other entrepreneurs, developers, IT professionals, and businesses small and large have been able to support our families because of Lotus products and their value to the businesses who rely upon them. Then, last week, IBM's Ed Brill quietly announced on his blog the sunsetting of the Lotus brand. Notes and Domino will be with us for quite some time (after all, so many companies rely on these workhorses), but the Lotus brand is officially now one with history. I'd rather keep the brand and lose the software, but maybe I haven't used it enough...
|
|
|
|
|
I know there are a lot of people who made a lot of money supporing Lotus Notes. I avoided it. Don't know if Sharepoint if better or worse, but think they are similar. It is also a pain to work with, and people make lots of money supporting Sharepoint.
|
|
|
|
|
|
|
I do not understand the message!
|
|
|
|
|
See the thread posted just before yours.
|
|
|
|
|
Looking over the link, it seems to actually indicate that they are equivalent.
|
|
|
|
|
If you see some of the comments, which I agree with, the extra capabilities of the List seems to be the deciding factor for many.
|
|
|
|
|
[ramble]
Regardless, I still have a sense of distrust when using Linq, and I'd be rather loathe to use it for large (more than a few hundred) records, and I imagine that if the expression (if your processing data from a database) will still run considerably faster in native SQL on the database server itself. Plus, debugging those IEnumerable<T> and friends collections is rather impossible unless they're converted to List<T> first. The debugger definitely needs to be more helpful! That said, Linq (and lambda expressions) are definitely very sexy for certain things!
[/ramble]
Marc
|
|
|
|
|
I try to keep to the LINQ Enumerable, but definitely do not like it. The advantage and disadvantage of the LINQ Enumerable is that the LINQ statement is only executed when it is needed; That can cut down memory, and processing. Of course working with them in the debugger can be painful since you have to physically cause the LINQ to be executed with the Expand results. Also, after a while can no longer even get the LINQ to execute. I therefore will sometime convert to a List when programming so that debugging is easier, and when I am finished, convert back. I have also found that I need to convert to a List when working with EntityFramework because errors cause once out of the Object Context. I also have found that working with WPF binding, it can be advantageous to go with a List.
|
|
|
|
|
It makes sense that if theres an array and a list of the same type that there would be some additional overhead because of the added benefits of the List type. I like that linq gets rid of my for loops with lots of nested if statements.
I have been using resharper from jetbrains.com to rewrite my for loops with nested if statements and boolean logic to LINQ and now I can write my own basic lambda expressions and im finding more uses every day.
|
|
|
|
|
I think most experienced programmers really like LINQ. It definately cuts down on a lot of code. However, and you have obviously learned, there is a significant learning curve. I have also learned a lot from resharper.
|
|
|
|
|
if data will be changed later (insert,update,or delete) you prefer to use ToList().
|
|
|
|
|
Obviously a ToList is a lot more flexible. Since the performance is slightly greater as a small cost in memory, ToList seems to be the better choice, even if you will not be needing to make any changes. I can think of very few times it is worth do ToArray.
|
|
|
|
|
.NET applications sometimes need to work with external processes. In some cases it is necessary to wait for those processes to generate results and exit before the .NET software continues executing. Waiting in this way is possible using the Process class. Here's how it works.
|
|
|
|
|
That's news?
|
|
|
|
|
Nope, though I think it's an interesting tidbit and it's news to me. I've been working with .Net for the better part of a decade and this is the first time I've seen such a thing.
Of course, I probably would have found it if I'd been looking for it, but this may spark some ideas of how I can use something like that.
|
|
|
|
|
|
At best a tip, and a pretty lame one at that, IMHO.
/ravi
|
|
|
|
|
I was using Red Gate .NET Reflector earlier for same as it was free and with frequent updates. Now Red Gate has made that tool paid (about 35$) version so I found alternative tools from that I can see IL and C# code easily for free. Why we need to pay money if we can develop open source product like ILSpy? Which reflector tools do you prefer?
|
|
|
|
|
Terrence Dorsey wrote: Which reflector tools do you prefer?
I've been using JetBrains' DotPeek[^] but will check out ILSpy!
Marc
|
|
|
|
|
I was using .Net reflector for a long time with my previous employer until a mail was circulated officially not to use reflector anymore! for some reasons!
Now, I use ILSpy and its enough for C# needs!
|
|
|
|
|
VallarasuS wrote: a mail was circulated officially not to use reflector anymore! for some reasons!
Perhaps because it's not free anymore?
|
|
|
|
|
Most ideas come from previous ideas. The sixties, particularly in the ARPA community, gave rise to a host of notions about "human-computer symbiosis" through interactive time-shared computers, graphics screens and pointing devices.... Early Smalltalk was the first complete realization of these new points of view as parented by its many predecessors in hardware, language and user interface design. It became the exemplar of the new computing, in part, because we were actually trying for a qualitative shift in belief structures—a new Kuhnian paradigm in the same spirit as the invention of the printing press—and thus took highly extreme positions which almost forced these new styles to be invented. From early ideas about OOP to SmallTalk-80... in about 50 pages.
|
|
|
|