Yet even though we have Windows Authentication enabled for SLX, direct links to entities were being redirected to the Login.aspx page. Apparently, Forms authentication prevailed on pretty much every request other than to Windows.aspx.

So I did some digging around and after understanding exactly what the redirection methods were (Nicholas Galler’s explanation shed a lot of light on how the HTTP requests are processed), I decided to roll something quickly (instead of implementing another MembershipProvider) with 1 new page and a modification to 2 files.

First, I created a standard page with a querystring at the end that contained the URL I wanted to redirect to, and added that to session. Next, I redirected to Windows.aspx – this redirecting allowed the 401/200 statuses mentioned in Nick’s blog to be generated. Without these, Forms auth would take over and we couldn’t capture Windows credentials (the user just gets redirected to Login.aspx again).

Next, I modified WinAuthLoad.aspx.cs like this:

         if (Session["MyRedirectUrl"]  == null)
{
Response.Redirect(Request.Params["next_url"]);
}
else
{
string url = Session["MyRedirectUrl"].ToString();
Session.Remove(“MyRedirectUrl”);
Response.Redirect(url);
}

For the life of me, I couldn’t find where next_url was being defined. I searched the entire project and couldn’t find it. I got some odd XML parsing errors playing around with it; if anyone knows where this variable is, I’d love to know.

Anyway, we don’t want to mess with it, because normal requests to Windows.aspx (for example, if someone’s visiting the SLX site normally) wouldn’t be able to redirect users to their configured default page. Basically this says “if there’s no session variable, do what you were going to do in the first place”.

The last step was modifying web.config. If you drop this new page at the root, it would be protected by Forms auth – you have to add a new element to allow access to everyone:

<location path=”MyRedirectPage.aspx”>
<system.web>
<authorization>
<allow users=”*” />
</authorization>
</system.web>
</location>

And that’s it. Now applications that need direct entity access via URL will work just fine.

So I went down the path of creating custom controls and importing them into my project through Application Architect. They were very basic List views, but they worked… and yet I was not satisfied. Not only were the advanced features unavailable, but it completely disrupted the user interface; controls available in every other List view were not available here. The inconsistency was bugging me.

I set out in search of any articles that described how to add outside data sources to SalesLogix. The only thing I found was a 7 year old article from slxdeveloper.com that actually describes the very problem I was trying to solve… but it described a fix with SQL Server as the database. We’re using Oracle 10g.

Another developer had the idea of using Oracle Synonyms to try to circumvent the problem. It almost worked right out of the box, but I had to spend some time tweaking the steps. The result is a pretty sturdy, reliable method of accessing these outside tables as normal SalesLogix entities.

You’ll need permissions to create views, synonyms, and a database link in your Oracle database. Without these, you won’t get very far. These steps assume you have these permissions already. And if you need to make updates on these – well, I haven’t gotten that far yet but I am pretty sure it will not work without true Standard Ids. But without further ado, let’s assume the following:

You have an external table called ORDERS. You want to present this table in SalesLogix in read-only format, and work with it like a regular entity.

Step 1. Create a view.
You’ll need to create a standard Oracle view, pointed to the external table, that contains all the fields you want to include in your entity. Give it a meaningful name. In our example, the view would be called ORDERS_VIEW.

Step 2. Create a table in Administrator or Application Architect.
Create a table and give it the name of your desired entity. In our example, we’ll call the entity ORDERS_VIEW_ENTITY. Take note of the table’s ID field name – you will need this later.

Step 3. Add fields to the table.
Add fields like you normally would… except they must exactly match the column names in your view created in step 1. If they are not exact, they will NOT work.

Step 4. Drop the table in Oracle.
Go back to SQL Developer (or whatever IDE you’re using) and drop the table you created in Step 3 (DROP TABLE ORDERS_VIEW_ENTITY).

Step 5. Create another view named after the table you just dropped.
In your IDE, create a view with the exact same name as the table you dropped (CREATE VIEW ORDERS_VIEW_ENTITY)). You’ll basically write the exact same view statement as you did in Step 1, except you will add an extra field to account for the ID field that you noted in Step 2, and cast your original table’s Primary Key as it’s value. So, it might look like this -

CREATE VIEW ORDERS_VIEW_ENTITY
AS
SELECT CAST(ORDER_ID AS CHAR(12)) AS ORDER_VIEW_ENTITYID, ORDER_ID,
…
FROM ORDERS_VIEW

Just make sure the alias you give it matches the ID of the table you dropped.

Now you can go back to Application Architect and add your view, and if all went well, you should see your fields and everything will work normally after clicking Build Interfaces and Rebuild Web Platform.

You’ll know it didn’t work if the following occurs:
- If during the Rebuild the Build Output window just outputs the same error message over and over (just delete the entity and start from Step 1) – this means your ID field probably doesn’t match what it was supposed to be
- If when you expand your newly added entity you do not see the column alias for the ID.

That’s it! If you have any questions, post in the Comments and I’ll do my best to help.

http://www.docondev.com/2010/09/motivating-unmotivated.html

Suffice it to say that I am very proud of how far I’ve come since then. And to do that I had to “get right” with myself first. Establishing respect for myself, for others, and our shared chosen profession has been critical to this self improvement.

Thanks, @docondev.

But I also think that there should be an opportunity for developers to justify their choice of tool. And if the team buys in, then ideally, the tool propagates itself by one person demonstrating how useful it is. The justification should never be based on personal convenience, but should include demonstrable productivity gains or in improved QA, to name just a couple of examples.

This happened to us when attempting to implement Git within our organization during SalesLogix development. We got hit hard. And while the details will be saved for another post, I wanted to provide some introductory context for this post – why we’re using Subversion now instead of Git for SalesLogix development.

So hold your thoughts on that. Here’s the good stuff. The process is, as far as I know, not documented very well, and I hope this changes that.

This assumes that you have the tools of the trade needed for this – Visual Studio, a valid Subversion repo, AnkhSVN, and TortoiseSVN.

1. In Application Architect, back up your VFS.
2. Create a new project workspace. Do NOT choose “Create Files on Export”.
3. Restore your project using the ZIP file created in Step 1.
4. Build your project. Do NOT deploy it. Doing so will add a new Deployment directory, which you do not want to add to SVN.
5. Using TortoiseSVN (or tool of choice), modify your local Global Ignore file (you can copy and paste this right into the Global ignore pattern textbox in TortoiseSVN). This includes files recommended for ignoring using Git, as well as some other common .NET files that should be ignored.
   

   modelindex.xml *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc
   *.pyo *.rej *~ #*# .#* .*.swp .DS_Store *.BASE *.LOCAL *.REMOTE *.orig
   deployment *.suo *.ncb *.user *.ccscc *.cache *.bak  bin obj
   Generated_Code ClientBin Thumbs.db

6. Check your code into your repository. You can do this from whatever folder level you wish, but to reduce confusion, keep Model as the top level folder.
7. You now need to create your working copy. Create another project in Application Architect, same as in step 2. Just point it to whatever folder you want to be your working copy. Remember not to export files.
8. Check out the source from your SVN repo into your working copy. You should now have the latest source from the repository starting at the Model folder.
9. Build the project in Application Architect. This will be your “de facto” development directory.

Now, for the nuances. If you do a local deployment,  you’ll notice that a new Deployment folder is created (under Model, and it should have the ignore overlay from SVN). In addition, if you check your target deployment web directory, you’ll see that a ton of _SVN folders are there too. This is because Application Architect is outputting the source it needs in order to get a working web version, and it’s including the SVN folders. These web files, as a best practice according to Sage, should not be under source control. This isn’t a problem with Git, because Git doesn’t keep files at every directory level.

So after deployment you’ll have to delete all the SVN folders in the target web directory. You can either do it with Windows search, which is easy, but we are working on adding it as a build step using NAnt. However you choose to do it, make sure you do it! If you don’t you will potentially ruin your check-in.

Next, this also assumes that you’re adding SmartParts the right way, through Application Architect. Sometimes I like to create SmartParts in a “quick and dirty” way to test some functionality. By this I mean I’ll create a control right in the web app using Visual Studio, then move it manually to a target server (usually development).

However, in order to preserve source control on these, these controls have to be properly created in Application Architect, or added as a custom SmartPart. To be sure, this is true for whatever VCS you use with SalesLogix, so just consider this a friendly reminder. Remember – never check anything in from Visual Studio.

Got a different/better way? I’d love to hear it. This process came about from a week or so of tinkering with the build process, but I have a great understanding now of how it works.

1. Create a new Filter (any Entity)
2. Save the filter
3. Build your project in Application Architect
4. Deploy
5. Edit your Filter, then rebuild your project
6. Deploy your changes.

You’ll get a nice error message that looks like this:

ERROR – Unable to retrieve deployment items from deployment provider : Sage.Platform.WebPortal.Design.EntityFilterDeploymentAction

ERROR – Object reference not set to an instance of an object.

ERROR – at Sage.Platform.WebPortal.Design.EntityFilterDeploymentAction.<GetDeployableItems>b__3(OrmEntityFilter filter)

at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()

at System.Linq.Buffer`1..ctor(IEnumerable`1 source)

at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)

at Sage.Platform.WebPortal.Design.EntityFilterDeploymentAction.GetDeployableItems(PortalApplication portal, BackgroundWorker worker)

at Sage.Platform.Deployment.PortalDeploymentManager.<>c__DisplayClass7.<GetPortalDeploymentItems>b__5(IDeploymentActionProvider provider)

Now, go take a look at your Filters folder in your VFS. All your filters in your entities are gone. The only way to bring them back is to completely shut down Application Architect, reopen it, rebuild, then redeploy your project.

Turns out this is a bug in 7.5.2. According to Jason Boyce:

The issue is changing the type on an existing (already persisted) filter in the filter editor causes the filter’s associated FileInfo object to be nulled.  This causes the deployment exception when trying to use that null FileInfo object as a file source and explains the “Object reference not set to an instance of an object.” error.  This error causes no filters to be deployed.
One of the last steps in a deployment is cleanup, which removes files not in the deployment list, which are assumed to not belong on the target.  Since no files are included in the deployment list in this case, all the existing filters on the target get deleted.

The original thread can be found here: http://community.sagesaleslogix.com/t5/Developer-Web-Discussions/Deployment-Issue-When-Creating-New-Filter/td-p/14541, but in the interest of disseminating helpful information I’m reposting the solution and video replicating the issue.

“We want to improve so we’ll start by hiring great people”. What makes you think the(y) will still be great *in your organisation*?

I jumped on top of this. It was an early Wednesday, and I probably hadn’t had enough coffee yet. But I was immediately put off by this statement. To me, it’s kind of a contrived statement. Those things that make people “great”, in my opinion, are attributes and characteristics that transcend industry, organization, and job. Caring about quality, your fellow co-workers, and your personal performance, among other things, are not things that are strictly limited to software development. My point is that it makes complete sense to use this as a starting point (although admittedly a nebulous one). Interviews are the beginning, of course – if you use good interviewing questions and techniques, you eventually begin to get to the bottom of whether the prospect shares your perspective.

Anyway, I retorted with:

isnt that what thorough interview screening is for? For the org and the prospect. This statement feels contrived.

To which the original tweeter replied:

Quite contrary – personal performance contributes to only 5% of org. performance, so improve the other 95% first

And he tagged it with Deming. Now, I don’t know where this measurement came from, but I find it hard to believe that the ratio of personal development to an organization’s responsibility to “make people great” sits at 5% to 95%. It’s not realistic. It’s outdated and doesn’t reflect today’s development needs at all.

Spolsky says it best in his Guerilla Guide to Interviewing – and makes an important distinction between skills and aptitude. The Tweet of course misses this nuance – and I doubt it could be fit into 140 characters – but its an important point to make in my opinion. You can be a skilled [insert job title/industry here], but not have the aptitude for analysis, communication, or collaboration. Interviewers naturally look for these among a number of things; Spolsky mentions one in particular – between being “smart” and “getting the job done”.

To me, people who “get the job done” don’t have to rely on an organization for personal development. They are self-starters. They are the ones who own pet projects and are passionate about technology. They are the ones who are not intimidated by unfamiliar technology, but have the experience behind them to know the best way to approach problems. These are the people who, with proper management, are innovators and difference makers in an organization. As an interviewee, it is up to you to determine whether the management at the organization you’re interviewing at is going to support you with the flexibility and freedom needed to innovate. That’s how I know they will still be great in my organization. There’s a symbiosis that cannot be ignored here.

The bottom line is there’s a mutual responsibility, but the interview should be designed to determine just how willing the other party is to assume their fair share. As a leader in my organization, I should provide every reasonable opportunity for you to improve your skill set, your knowledge, and your career development. As an employee, I should be willing to ask for and take advantage of these rare opportunities as they present themselves. I am not entitled to anything, and I think developers today should be wary of this entitlement syndrome.

In Git Extensions, the Commit tab with details on the last commit has a spot for a Gravatar. I thought it would be a fun exercise to arrange an understanding among the team that if they break the build, the penalty has to be an embarrassing photo of some kind. Nothing like a shaming ritual for team-building.

With that in mind, I went surfing for some appropriate pictures. Here are some of my faves.

I love this T-Shirt.

If you have other good ideas for fun finger pointing when the build breaks, share them with me.

The result? I was given free reign to implement source control as I saw fit. As long as it was with Subversion. See, all of the other internal company projects use Subversion (every other project outside of this department’s projects is properly source controlled), even though  SalesLogix heavily supports using source control with GitHub, complete with supported addins for Application Architect.

The main reasons I could not get approval for Git were:

1. GitHub for “real” development costs money. Sure, it is free, but in order to maintain any privacy or administrative supervision, you need to purchase a subscription. And it’s relatively inexpensive initially, but when added to the costs of managing a new tool and training others on using Git, ROI realization wouldn’t come quickly enough when compared to a free tool that we already know how to use.

2. What if we got hit by buses? If these specific developers left, the organization would be left looking for developers with Git experience, or take the time to break the source control rev cycle to re-apply it to Subversion. Not an option.

3. Saying “it’s secure” isn’t really meaningful. In other words, administrators get more warm and fuzzies knowing that their security practices are the only thing between developers and unauthorized users. Sure, Git says they are “secure, backed up, and always available”, but to the unreasonably paranoid, this isn’t enough. They want to hold the keys and control who gets to use them.

So we couldn’t use Git. I had to use Subversion. The problem here is that Subversion resources for SalesLogix are pretty much non-existent. Sure, source control is straight forward, but there are some subtle nuances with builds in Application Architect that need to be accounted for. So after a lot of trial and error, along with culling information from a few sources that focus on Git integration, I have cobbled together a first pass at using Subversion with SalesLogix web development. As of today, this works.

If there’s something I missed, please let me know in the comments. I want to work hard to make this a living document for others who have a similar task ahead of them.

This assumes you have all the required tools, natch.

1. In Application Architect, back up your current project workspace. This is your fail-safe for the moment if anything fails. Park this in a safe place.

2. Create a new project workspace. Give it a meaningful title. Do not choose the Export Files On Creation option.

3. Perform a restore in this new project workspace that points to your backup.

4. Close Application Architect.

5. Navigate to the directory that contains the VFS model and copy it to a separate location. This may not be needed, but it’s just me being a paranoid developer. I make no apologies for this.

6. At your new separate location, add the folder to your Subversion repository.

7. We’ll now create a working copy directory, so create yet another blank folder somewhere.

8. Do a checkout of the code you added to the repo, and check it out to your working copy directory.

9. Create a new project workspace in Application Architect. Again, do not select Export Files On Creation. Point the folder to your working copy directory.

10. In SVN, set Ignore on the Deployment directory, and modelindex.xml at the root of the project directory.

What you’re left with is development out of your working copy, and once you check everything in, you or someone else can either bundle the changes to your target server, or you can copy the entire Subversion directory to your target server and bind it to your workspace (like you did for this exercise). For multiple developers, though, you will want to make heavy use of KDiff3 or some other diff and merge tool. This isn’t as daunting as it sounds.

I have noticed a few oddities that I’m not sure yet are really oddities. The most pronounced one is that source control is persisted to output files deployed to your local IIS instance. According to the official SLX Training Blog, Jason Huber ends his article with the following statement:

“Do not place source control on the output files (C:\inetpub\wwwroot\slxclient). This makes no sense. If you want a copy of these files then use a deployment snapshot instead. This was also covered in boot camp and in the various classes offered at Sage.”

I don’t know why, but Windows shows everything in SLXClient as under source control, even though the deployment folder is being ignored. But we are just now starting multiple developer efforts, so I suppose we will learn one way or the other whether this hoses anything.

Efforts to reach out to the SalesLogix development team and other resources for answers to these questions went unanswered. There’s a few postings over at the SLXDeveloper forums that I left that have gone unanswered also.

Resources I used to assemble this article:

Ryan Farley’s blog over at CustomerFX
The SalesLogix Training Blog

When I was given the title of Technical Director at my last place of employment, part of my responsibilities involved managing people. Just one or two people… ok, just one (and I can’t imagine what the disaster would have been if there were more). The position I managed was a junior developer one, and for my five years there, the position had a lot of turnover.

Looking back it was easy to see why. We had to hire under schedule pressure. The region had a real dearth of technical talent (and upper management reluctant to support a telecommuter). Previous projects were not executed well, so the junior dev had to handle frustrated, angry tech support calls (hey, I’m too busy to take this call, and you’re Tier 1 anyway). At the risk of sounding emo, I felt like I had to pick the best of the worst. But I also felt I had a responsibility to bring out the best in them and help them become a better developer and a better employee.

So… meet John Doe, known as John for short.

We hired John in October 2008 when we were desperate to fill a void left by our previous developer (he got his MBA and “got out”). John had some experience, enough to justify a junior developer hire, but I knew I had my work cut out for me from a training perspective. He was new to .NET, but not to ASP or web development, so after telling him that he would need to learn .NET in order to complete his day to day job duties, we agreed to give him a shot. I decided I would take him under my wing and help him learn enough to stand on his own.

Here was my first out of a thousand mistakes. I assumed that John would have the same zeal for technology as I did. In my mind I’m thinking, “you are getting paid to train! How many people can say that? What a great opportunity for you!”. I provided him with short question and answer meetings, training materials, and offered company reimbursement for other materials or courses he wanted to take. But he didn’t really care, or so it seemed.

Anyway, John didn’t pick up on .NET quickly. But we muddled through projects. Soon his first “big” project came along for a major client. It was in C#, but he was primarily a VB.NET developer. We let him do it anyway. We didn’t have much of a choice, as I was on all the other “big” projects. Needless to say, it was only mildly successful.

An adjunct project arose for the same client and I grew frustrated as my workload increased exponentially because John required continuous handholding in his C# and .NET training. I was irritated that he didn’t pick it up “fast enough”. I watched as he “did his job” and did not, as I saw it, “go the extra mile”. For me this meant working longer hours to make up for the loss in productivity, mostly. Basically I wanted him to suffer like I was suffering (and I was, I was working 65+ hour weeks with a new baby at home). I was starting to harbor resentment towards him, and the working relationship started to turn sour.

So I started to look at how we were motivating John, and I realized we really weren’t motivating him at all. I decided to start motivating him. I kept thinking about Gunnery Sargent Hartment, the drill instructor from the movie Full Metal Jacket.

It worked for him (well, almost). But for some reason I became fixated on exactly the wrong approach to motivating John.

The first thing I did was give him the “guilt trip”.

“John, you know, we are all working pretty hard here and you’re leaving right at 5pm. What gives?”

John just kind of shrugged his shoulders and didn’t really know what to say. After about 20 minutes of “you know we all have to work extra special hard to make this company work” nonsense I let the guy get back to work.

And he left right on time.

Since that didn’t work I decided try some “carrots”. We waved bonus money at him for any extra hours worked (we worked on hourly rates, so we had a target billable rate every week to make just to break even). And it sort of worked, until the billable work dried up, or projects were at a net loss (so no bonus was earned at all).

So John continued to leave right on time.

I was angry by now. Here I was, putting forth all this effort, and this other guy who can’t code his way out of a shoebox is just getting by… that by itself didn’t annoy me – it was that he didn’t give a shit.

So I went on screwing up this guy’s development future by putting him on “probation” when bugs he claimed to fix kept recurring. When he “sicked out” of an important work day that was tied to a deadline for an important client, I put him on double secret probation.

When he came back from his sickness, he left at 5pm.

The last straw with John came when we needed extra hands to help with our company’s largest project ever. We communicated this to John, that it was big and important, and I tried to play up the “personal growth” angle. And since I was overworked I didn’t pay attention to John’s work in the “right way”. I managed by “walking around”, and that didn’t work with John for a number of reasons.

One day I walked around and found that John had billed almost six weeks worth of work to our client and no work was done. He claimed to have lost it in a tragic source control accident. Then when we tried to recover from older revisions, he claimed he never checked anything in (basically he left files open for six weeks). After another angry outburst, John was let go a week later. I left two months later.

Looking back I realized I’ll never behave that way to peers or colleagues ever again. But at the same time I can’t help but wonder what in the world would have motivated this person? Money didn’t work. Not punishment, not public acknowledgement of success, not training. I couldn’t elicit anything out of him that he was excited about (except college basketball). I took out my anger and frustration on him because I could not motivate him. And when he didn’t care that I was angry and frustrated, it kept the cycle going.

This is a short version of the story. There were other incidents that were serious but don’t change the overall point of the story.

So here’s the question – what do you do to motivate the person who is semingly unwilling to be motivated?

Do programmers have quiet working conditions?

It used to be that programmers and developers were perceived as the shy, almost anti-social type. This rule doesn’t help to debunk that stereotype, either, never mind that this kind of PERSON, let alone developer, does not have a high degree of career success (that’s up to you to define, I suppose). But Joel is right on – programmers need quiet working conditions. I didn’t have one starting out, and it was a tough gig.

His argument is in some ways “perfect world” – let’s be realistic, not every programmer can have an office door – but there are other options. Headphones are probably the most popular (although at a start-up I worked at, one guy taped garbage bags around his cube, making a roof and a curtain). Some people have the opportunity to work from home, the ultimate in controlled working conditions. I do both, and I’ve gotten good at establishing a quiet work environment. while still remaining accessible.

• Instant Messenger statuses. My personal favorite. Create a friendly “busy” message that lets people know you are busy and should not be interrupted. Then, disable instant message windows in busy mode (this doesn’t make flashing windows a distraction). Finally, leave a phone number to reach you if the request is urgent. This forces people to truly consider whether they have a critical need. By the same token, turn it off and make yourself accessible when the timing is not critical.
• Scheduled email reviews. This doesn’t work for everyone, but I like to shut my email client down and only open it at certain intervals. If something came through that was critical, in my opinion, a phone call is warranted. It can’t be that urgent if it was sent over a comparably unreliable medium like email.
• Turn your phone on. These don’t work if you don’t have your phone on. You’ll only make enemies.
• Pre-planning goes a long way. If you have a planned flow session, go to the bathroom beforehand. Keep snacks and drinks nearby. Have your to-do list at hand. Turn off Twitter, RSS, Facebook, etc. These can be incredibly distracting! They are to me, anyway.
• Get one of these – a monitor rear view mirror. Or, you can just go to your local auto parts big box store and get a mirror for two bucks, then use the tape it comes with and attach it to your monitor. You can now work quietly, checking your rear view every now and then to see if anyone’s hovering. This is what one looks like.

Remaining accessible, or giving the perception that you still are accessible, is critical. Development is almost always a collaborative effort, and you’ll never be able to shut people out entirely (if you do, consider a different gig!). But you can give people the illusion of accessibility and still work, for the most part, uninterrupted.

Got any other tips to share?