One difficulty that he was running into was the occurrence of duplicates that were taking place during the generation of the collection. He was questioning if it was workable to inspect and eliminate duplicate SPList objects that occur before returning the final SPList collection.

In order to do this, we of course necessitate a unique identifier for each object, so it makes sense to use the SharePoint generated SPList.ID property which guarantees a unique value. Within the method, we are creating two other collections, a temporary typed dictionary object which will hold the ID values to later act as a guard clause, as well as a provisional SPList collection which will provide return allocation.

That should do the trick!

:)

Share This

Recommend This Post

:)

Share This

Recommend This Post

If you scrutinize the achievements of these endeavors however, they may initially appear promising. However, numerous sponsorships disappoint in generating durable growth. While the present Columbia administration seems to be baffled as to why this is the case, I feel that I can sum it up pretty effortlessly and save the residents of the city I love some tax dollars. I am a nice guy.

The funding for these programs adheres to fundamentally identical external and internal processes subject by any government grants. It is not especially remarkable. And quite honestly, I don’t think it is an internal issue which is the problem. I guard with this because most of the articles I have read dealing with this seem to revolve around this being the massive bottleneck.

Simply put, it is the programs that are chosen to be funded. The result of the malformed selection process results in the proposed economic development not benefiting the residents of the Columbia with long term growth.

The programs that are selected target explicit populations, habitually not being directed at progressive, bleeding edge industries. In addition, the programs selected generally don’t lead to supplementary jobs that are clerical in nature, or if we want to put it how Uptown Sinclair put it, white-collar workers with a high ratio of disposable income (was that blatant?). This sole fact alone generates a stagnate as opposed to economically dynamic society and environment. When there is relatively little disposable income that is being enjoyed by a select few, there is no real possibility of creating a mass domestic market for new development. While the median income of South Carolina would immediately observe that current decisions would actually be the most pragmatic action, all it does is lead to cyclic behavior that keeps Columbia in economic shambles.

This is a constant truth and presented in some of the most studied economic works. For example, examine one of the most celebrated economist / authors / urbanists, Jane Jacobs in “The Economy of Cities”. She clearly indicates when there is more disposable income available for domestic investment it will in turn lead to a more prosperous economy. Not very shocking. If the current administration desires to grow and maintain Columbia the focus must be shifted from strictly manufacturing and low-level service industries in order to make the city more viable. It’s as simple as that. To be blunt to the administration, you are investing in the wrong shit.

I am in no way saying that the conventional and time-honored brick-and-mortar industries that are terrifically southern cliché can’t play any role with this process. That would be obtuse and rigid. However, I am professing that the focus needs to be shifted onto more progressive industries with what some may consider an unfair balance in order to really cultivate the city with long-term growth. When this crops and further businesses start to use Columbia as an economic hub, it will bring new population, more disposable income, and in turn more domestic investment. I mean really, this is not astonishing or pioneering stuff I am encouraging. You are equipping the wrong type of businesses and really putting the residents that you are responsible in a self-defeating situation. You are asphyxiating, not promoting expansion.

I believe there this is physical evidence that this is indeed the case as well. If you walk down the greater Columbia area, you will notice Main Street which leads to the Capital building, quite a site! If you walk further away from the capital building (East), I am guessing around 4 blocks, all of a sudden you feel like you are walking in a dying area sponsored by a 1940’s Humphrey Bogart film. And I am not exaggerating, I believe that the median amount of buildings up for lease on that one street must be near 70%, while the other businesses that are currently open look so deprecated you would have to be mad to consider them actually applicable. And this is Main Street. Although the lack of growth here makes it clear of misdirection of the administration, it would also make the point that most government direction is leaning towards manufacturing. I have never seen any larger offices for some of the manufacturing organizations (although I just looked for brick producing enterprises) and generally plants and other such faculties are not held directly within a downtown area. There is adequate space to use though if they wanted to. What I am trying to emphasize is the intended chief street in Columbia is destitute. And that’s where businesses SHOULD be congregating.

To sum it up, I am not promoting innovative economic creed; a majority of what I have put in here is taught in introductory undergraduate economics classes. That part that I find most wearisome is that Columbia administration ostensibly skipped that day that basic economics was covered. And then forgot to pick up a book. And then kinda sucked at their jobs.

:(

You make me sad Columbia administration.

Share This

Recommend This Post

So, then I write some debug scripts, and find out that as a substitute they copied over the database structure when moving the site, leaving most of the content. I mean who does that? Observably the consequence of this inaptitude was that the site was incapable of delivering anything.

Regardless, it is all resolved now. It was just some time on a Sunday that I didn’t really enjoy spending on something that I already pay someone to make certain doesn’t happen.

Outside of that, TechEd went well. Thanks if you came to my session on SharePoint security! I will be posting the code from that session this afternoon into separate posts.

Share This

Recommend This Post

I will in fact copy and paste it directly from the offered advertisement text:

SharePoint Programmer / Developer / Architect: Must have at least 7 years practical work experience in C# with building solutions on top of SharePoint. 7 years Java experience to support conversions of J2EE to .NET solutions. To support this role, 5 years of Oracle and Delphi experience preferred. 5 years experience required with MFC/ATL and Crystal Reports.

Must have 5 years of deep architectural experience with building large SharePoint farms, and administrating them in the same capacity including deployed custom development. Several years architecting and developing against ISA and MIIS preferred and encouraged, however not required.

Interestingly enough, on recruiter sites you are able to spot precisely when the job was posted. The antiquated date appended to this made sense to me since this particular position has been open for over half a year, borderline 8 months. And I will wager that no sensible applicant has dared to apply to this gobbledygook.

Why?

Because not only does the ad undoubtedly convey that the posting recruiter did inadequate technical research because of the erroneousness of technical dating (which offends job seekers btw), but they must be looking for the fabled nine armed, four brained mythical programmer that they prophecies foretell of, because for all intents and purposes those requirements are outrageous.

First, let’s pick apart the ad.

7 years of C# development experience, while being feasible, is marvelously atypical since the establishment of the C# language in common commercial markets is roughly in late 2000. So, this organization is most likely looking for a C# beta tester for when Anders Hejlsberg was still calling it code name “Cool”. Needless to say, this would be exceptional and uncommon.

7 years of .NET development on top of SharePoint I can see being a qualification, if STS (2001) development actually used .NET. Then it would be cool. But it didn’t. So the basic arithmetic of the recruiter sucks. Even then, you would be subject to the same time considerations as described above, making it not necessarily common.

5 years experience with MFC/ATL? Huh? I mean, I did MFC / ATL programming for a long time (it paid for college), and I have to admit I really don’t use that skill set outside of the far reaching development concepts very often. It just isn’t obligatory for ordinary SharePoint business development (note the use of the word ordinary there).

I actually can understand the Crystal Reports one. I guess. I mean I don’t use it, but it seems like in some circles it could be interpreted as a pragmatic requirement. I guess.

The conversions requirement made me sort of laugh, since that is a pretty specific skill set to want out of a developer. Because of this, as well as the larger noted SharePoint development experience, I think the organization might be more successful with breaking this into two separate jobs. To me, it’s kind of like walking into a barbershop, getting a haircut, and then asking why the barber didn’t go wash your car and walk the dog. Lazy bastard. I think coupling a C# developer that has rudimentary Java skills with a Java developer with basic C# skills would produce higher quality code conversion, most likely in a more reasonable time frame since those two programming schools tend to stay siloed in their language of choice. Even though in my experience code conversions just end up being a software rewrite anyways.

When the recruiter starts to talk about wanting the SharePoint developer, architect, and administration full package, I start to get a little frustrated. While there are certainly people that can wear all these hats, very well too, generally they become too busy divvying themselves up between tasks spawned from owning those assorted roles habitually those tasks never near completion. Only little increments are accomplished, never leading to closing. People often times like to specialize in a certain aspect additionally, and pride themselves in knowing all the ins and outs of that niche. I like doing architecture, but I love doing development. Furthermore, I simply loathe administration. It doesn’t mean I can’t do it; I just don’t enjoy it as a job role. It doesn’t blow my hair back.

The ISA and MIIS requirements are asinine if it is anything but a proof of concept or a small deployment. This should be principally noted with the MIIS requirement; the recruiter should be looking for someone that continually focuses on identity management systems when standing that up. Knowing those concepts to the metal vastly increases chance of project success. Like I said in a previous point, you don’t ask your barber to cut your grass. Unless your barber is just genuinely charitable and bored.

Consequently what happens when you are the recruiter that placed this ad out into the wild? You do a dance of joy because low and behold you found a hidden genius that satisfies hopeless requirements (not just meaning that they are hard, they really are impossible)! Yeah! Diamond in the rough! You rule! And he is willing to do it for 40k a year!

But what does your organization end up with?

The quintessential, yesss-sssir guy, whom only has the qualification of being a professional impostor and habitual liar. Fundamentally you have someone with an archetypal psychological complex tailored around satisfying people even though that satisfaction is bogus. Meaning, they are full of shit. I am not saying that to satisfy all the requirements is impossible (assuming that technology timeframes were right). It’s not, however it is decidedly unlikely. More than likely, they might *know* these buzzwords, read about it a bit, but don’t have deep experience. I have minimal Delphi experience, and very, very brief Oracle experience. Although I have used these, I don’t list them as skill sets of mine. I am not proficient enough. If they were mentioned at a job interview as required, I would throw sand in the interviewer’s eyes and flee on foot.

So I propose the following to SharePoint recruiters…

Firstly, be sensible with your project needs. I know it would be nice to have a methamphetamine IV feed developer that consistently practiced other technology facets locked in the closet that only required fish heads for substance doing your project work. I wouldn’t mind one of those myself. But it isn’t rational. When defining roles for a SharePoint implementation during the project planning process, it is healthier to have more jobs divvied up based on specialization rather than constrained numbers trying to overexert themselves out of their specialty. The former has proven, at least in my personal experience, while taking a large toll on budget tends to lead to enhanced quality of deliverables and probability of aggregate project success.

Secondly, tailor their SharePoint job ads to be more specific. Don’t be so vague. You clearly have a project, with a defined project scope (hopefully), project WBS’s (even though you are mocking people), and other project documentation. I don’t understand why this isn’t kept in mind when you are making your staffing decisions. I appreciate keeping it ambiguous because who doesn’t like the brain-surgeon-that-worked-charities-while-saving-puppies-from-burning-houses-but-now-does-awesome-SharePoint-development-guy, but your advertisement requirements are not practical. One of the most important portions of project planning is to define the roles filled by project team members and the responsibility of each role. I really doubt that there is just one role defined as “everything besides the project manager”.

Lastly, for Christ’s sake, research the technology that you are advertising for. You don’t have to know it very well, you just have to know it enough to *find* someone that knows it a whole lot more than you do. If I wanted to find a good dairy farmer to get some milk, I don’t have to know how to milk a cow or manage a farm, I just have to know the basics of the milk I want. The same goes when you are building technology requirements. Kinda.

Share This

Recommend This Post

In order to do this, you can use this simple method below:

If you wanted to firstly test whether the view exists, you can implement this as well based on what types of guards you wanted to realize:

Share This

Recommend This Post

Share This

Recommend This Post

The celebrated dramatist Oscar Wilde once said:

“A cynic is a man who knows the price of everything but the value of nothing.”

This quote to me means numerous things (since it is so open to elucidation), however none more exceptional than the simplest interpretation. A person at times can repeatedly put an empirical cost on an arbitrary object since this is, well, pragmatic. However, to get something that is not as tangible such as Realized Business Value (RBV) or Return On Investment (ROI) for a collaborative effort is remarkably curious. Although the cost is certainly going to play a parameter when generating your Realized Business Value Docket (RPVD), it certainly is only that, a piece of input while in the presence of other inputs that hold more weight (this is one of the strengths of RBV since it provides some basic levels of cost abstraction, and those living in the small-to-medium size vertical the purchase of SharePoint can be quite expensive).

I want to stress that in my opinion, measuring things like monetized ROI on collaborative software efforts leveraging legacy business value approaches is a façade, a mirage, an illusion (this might not apply to some of its subsets). Just don’t even try it, it’s self-defeating and will only suffice in providing a depressing, dismal night where you are fudging numbers more than harvesting from the actual project.

This isn’t to say that you can’t acquire value with output metrics with collaborative software efforts, but it is problematic to present your findings to management since they can prove to be abstract and often times contain a buttload of inference. Commonly, at a most basic level, a manager is going to expect that he can gain an object for a cost from someone and somewhere, and from these parameters as well as insight into the owning organization, an ROI can be determined and implemented. In the end, we can say that managers tend to be good at looking at a particular project with a pair of monetization spectacles, compensating for human factors like apathy to technology. Taking this monetizing approach when attempting to appreciate the value of SharePoint, as well as all collaborative software, is not practical however.

Why? The outputs are different. Plain and simple. Whereas with traditional software development efforts we can do the type of surveying of project results as described previously, this is unquestionably not the case with SharePoint. Collaborative software has outputs such as:

Augmented Information Worker Knowledge
Improved Employee Productivity
Enhanced Customer Service

And while I can name these out just fine, and in some fashion there may be some methods to garnish metrics from them (notably the “Enhanced Customer Service” entry), how does one place a value on something like enhanced information worker knowledge. While we can certainly see whether there are variations between productivity, this reporting is in essence very circumstantial because we are pretty much preparing a collection of facts rather than a conclusive series. There could be too many factors involved that could cause discrepancies for any of these during that process, as well as for the aggregate output.

So, stuff like this is somewhat conjectural at the moment. I think that the best way to measure something like this would be with revolving, time adjusted surveillance of collaborative software utilization growth and taking into account parallel visualization of the stored and delivered data. However, I don’t think that is enough, because that is only a very small part of the measurement. Rather, it would have to be inclusive to include the more human factors, such as how often a person is involved in face-to-face interactions, movement patterns that occur in the workspace, etc. This type of research would be even further constrained as it would have to compensate for dependencies on legacy collaborative tools, such as email. I am not going to go into the approach I would use with this, I will save that for another post.

I guess what to take away from this, particularly if you are a manager, is this is a new concept and a new type of recognition. And while the benefits might not be immediately available to conventional brick-and-mortar industries, they are there. There just haven’t been any mature, intelligent tools built that inclusively deliver those types of reports.

Yet…… (and the gears start turning). Stay tuned!
:)

Share This

Recommend This Post

http://lolcode.com/ 

Share This

Recommend This Post

Wish me luck during the finals!

Share This

Recommend This Post