Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Discussions

Stephen Schaff Vaccano Desktop developers are people too!
  • Microsoft & Oracle dragged into epic developer wage fixing conspiracy lawsuit

    , androidi wrote

    For some situations there might be a valid reason for some of the restrictions but what's likely is that such "valid reason" was quickly extended to everyone except those with bargaining power.

    One situation could be that there's few companies with tech in which skills are specialist on-the-job learned sort but are also transferable to competing company. (though similar fear could be assumed for transfer of IP or clients). If the new hire learned these skills on the company dime and then soon jumped to the competitor because just not liking the place or got better offers (just when they were about to actually be valuable to the company where they learned the specialist stuff), I could understand if the employer would have serious issues there.

    Now how would the right balance here be implemented in unambiguous manner? To avoid things getting too complicated, perhaps the "test" should be related to what you presented in your CV and what the employer presented in their official job add. If the job you end up is something not in your CV already and is found listed in other peoples CV's, then you probably learned it on the job. In that case the employer should have "dibs" on you actually staying there for some reasonable time beyond just learning the skill. What that would be, no comment.

     EDIT: On the other hand, if the employee begins to feel "trapped", that surely can't be good for the company in the long term either. I'm kind of thinking that the "dibs"/non-compete length should be somehow related to how much the company actually invested in you - eg. if it took you x amount of time to get up to speed and perhaps some other person was not doing what they usually do for y amount of time, then these might factor into how long you should be expected at minimum to stay there. I'm just not sure if having this sort of restrictions is overall a positive because if the atmosphere gets poisoned/resentful or whatever due to someone feeling trapped, that could be really bad in long term for the company.

    This sounds a lot like a Contract.  My company has what they call "At will employment".  They say it means they can fire me, and I can quit, at any time.

    But if they wanted to ensure that I don't get valuable on the job training and then leave, a contract seems like the way to ensure that.  (I am a programmer, not a lawyer, so there may be a better term for "employment contract".)

    A contract has the benefit of not being as hidden/shady.  If I don't want to get locked in, I can just not take the job.  

    Hidden non-poaching agreements are evil.  And when done by several large companies, bring down the wage of the whole industry.

    Having something like a 2 year work contract when you get hired is going to make the job less desirable to candidates.  But that is the trade-off if you can't keep your employees at market level of pay and work environment. 

     

  • C9 same design for years?

    , Ian2 wrote

    Isn't the whole flat design thing coming to an end now?

    Oh I hope so!

    I did hear that it looks like MS is moving away from it a bit.  Not full abandon, but just some.

  • i really think new WP IE is low quality.

    I too have noticed that it is poorer. 

    Playing videos from WP IE has problems for me too.

  • Apple only supports Safari for their iPhone 6 Annoucement

    I think it is funny that you have to have Safari to watch the announcement. 

    It strikes me as a bit conceited.  It feels like they are saying, "We are so awesome that you will go download our browser just to see our awesomeness."

    When actually they just passed up an opportunity for them to get in some free advertising on me (a person who is looking to buy a new phone soon).

    UPDATE: Looks like you have to have an Apple device/OS too.  Lame.

  • Apple ​Announcemen​ts

    <started as new thread>

  • What % of people use Visual Studio Database Project?

    I have used it in several projects.  I have found that it is fantastic for getting started on a new project.  But once the project gets a year or two in, it just gets in the way.

    Lately we have stopped trying to use it.

  • Am I not getting it or did OData V4 go off the rails?

    , cbae wrote

    *snip*

    If the client application doesn't need these properties, they probably should be private to begin with.

    The client applications does need them.  But I am not allowed to expose them via OData because they are DateTime columns.

    Otherwise, you can make them DateTimeOffset in .NET and map them to datetime in SQL Server. You can manage the data type mapping through the Entity Data Model designer or in code using the fluent API if you're using Code First.

    As I said, the only way to do this (and preserve your naming) is to manually edit the Entity Data Model (CSDL) file.

    If you're using the Entity Data Model designer having to make manual tweaks is already unavoidable if you're mapping table columns to enums.

    Enums?  Who said anything about enums?

    At some point, just deleting all of the entities and re-adding them to reflect the changes to the database is not a viable solution to synchronizing the entity data model with your database.

    Sometimes delete and re-add is the only way to fix problems with Entity Framework data models.  Still, I don't delete everything and re-add.  I just do this to the affected tables/entities.

    Another thing you can do is to create a script that uses the API provided by the System.Data.Entity.Design namespace to automatically change the .NET type of any SQL Server datetime columns to DateTimeOffset in your EDMX file. As far as I can tell, a SQL Server datetime column implicitly converts to .NET DateTimeOffset, and a .NET DateTimeOffset implicitly converts to SQL Server datetime. So there's no need to add any special code like that in the StackOverflow page that you link.

    I tried just changing the type (I hoped there was an implicit conversion too).  But when I tried to run it, I got a type mismatch error.

    Basically, it can't be done without a manual edit to the CSDL or changing your column/property names.

  • Am I not getting it or did OData V4 go off the rails?

    , kettch wrote

    *snip*

    I've done this kind of thing before using partial classes. Since even the generated classes are just POCOs at heart, you can partial up anything you want and it will persist.

    If it were just partial classes I would not complain.  I have done that many times and it works great.

    However, as I said before, this work around requires manual modifications to the CSDL file.  That is unless you are ok with your "OrderedWhen" field being named "OrderedWhen1" or "OrderedWhenDateTime" or some such other name.

    And even so, you have to change the scope of the datetime property to private (so that it does not get exposed to OData).  This means that you have to remember to fix that if you ever regenerate the table (a fairly frequent practice with Entity Framework).

    I suppose I could do all that.  But that is just another layer of complexity in an already complex system.

  • Am I not getting it or did OData V4 go off the rails?

    , cbae wrote

    *snip*

    Are you using EF or any other ORM? If so, you should be able to map DateTimeOffset types in your POCO classes to datetime columns in your database tables.

    When you have a lot of these columns, the time to do it adds up.  But if it was one time work I could "bite the bullet" and get it done.

    But this mapping requires you to edit the entity framework's CSDL.  Since that CSDL gets generated code put into it, my changes can be lost when the designer updates the file or another developer drops and re-adds a table.

    Yes it is a solution, but a dirty one that should not be needed.

  • Am I not getting it or did OData V4 go off the rails?

    , kettch wrote

    *snip*

    Why is it useless? There is only one scenario where you wouldn't use DateTimeOffset: You are writing an application that will never do anything across time zones.

    Before you answer, consider the fact that due to the daylight savings transition, your app will cross time zone boundaries at least twice a year.

    I agree with this if you have the luxury of blue sky development (meaning you get to start from scratch).

    But if you have hundreds of DateTime columns in your system, and a way to deal with the timezone problem already in place, then DateTimeOffset is a lot of work to just get you back to where you already are.

    Which is why I am frustrated that OData decided to drop DateTime.