|
Well, I'm even more confused now.
The NOAA definition of Solar Azimuth, from their website:
NOAA wrote:-
azimuth and elevation - an angular coordinate system for locating positions in the sky. Azimuth is measured clockwise from true north to the point on the horizon directly below the object. Elevation is measured vertically from that point on the horizon up to the object. If you know the azimuth of a constellation is 135° from north, and the elevation is 30°, you can look toward the southeast, about a third of the way up from the horizon to locate that constellation. Because our planet rotates, azimuth and elevation numbers for stars and planets are constantly changing with time and with the observer's location on earth..
Gerry Schmitz wrote: The north pole doesn't rotate
The North Pole definitely rotates - if it didn't, nothing else would, and there would be one sunrise and sunset through the whole year, assuming the earth's rotational stasis with reference to the plane of the ecliptic.
Sudden thought - you're not a flat-earther, are you?
|
|
|
|
|
A senior citizen I know has a contract for Geek Squad, and while trying to get a minor issue resolved by a Geek via remote control, the connection dropped out, and now clicking on any icon comes back with a message like "blah blah not found".
What the h3ll is Geek Squad service worth if it ends up making the problem worse?
|
|
|
|
|
You are complaining to the wrong people.
|
|
|
|
|
It's not quite as bad as it originally seemed. The Geek was trying to get Google Chrome updated, and the connection cut off, causing this issue. Still, the Geeks should know how to deal with this situation.
|
|
|
|
|
I found myself with nothing to do this week, so I decided to make a concerted effort to repair the significant code loss I suffered back in May/2020 with respect to my entity factory app. I think I'm happy once again with the model generation, so I figured I'd post some code the app generated for me.
For those that have forgotten, EntityFactory will generate model (and optionally viewmodel) classes based on the selected table, view, and stored procedure (SQL server). What makes this app more functional than the ADO code generator is that it will generate an object for any stored proc that returns data, regardless of the method by which the data is returned (the ADO code generator refuses to work with stored procs that return data with dynamic sql, and re-generating code doesn't work in a number of spectacular ways). In the sample below, I turned on the generation of crud properties, just to exercise that part of the code. All of the code below was generated based on the returned schema for the indicated database source object. Processing took less than a second.
/==================================================================================================
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.ComponentModel.DataAnnotations;
namespace Models
{
public partial class EntityAlerts
{
#region entity properties
[Key]
public int ID { get; set; }
public string AlertName { get; set; }
public string AlertTitle { get; set; }
public string AlertMsg { get; set; }
public DateTime AlertStartDate { get; set; }
public DateTime AlertExpireDate { get; set; }
public int AlertType { get; set; }
public int AlertClassLevel { get; set; }
public string AlertApps { get; set; }
public string ActionName { get; set; }
public string ControllerName { get; set; }
public DateTime DateAdded { get; set; }
public int AddedByUMSUserID { get; set; }
#endregion entity properties
#region database properties
public string CRUDGet
{
get
{
return "SELECT [ID], [AlertName], [AlertTitle], [AlertMsg], [AlertStartDate],"
+" [AlertExpireDate], [AlertType], [AlertClassLevel], [AlertApps], [ActionName],"
+" [ControllerName], [DateAdded], [AddedByUMSUserID] FROM [dbo].[Alerts]"
+" WITH(NOLOCK);";
}
}
public string CRUDUpsert
{
get
{
return "UPDATE [dbo].[Alerts] SET [AlertName] = @AlertName , [AlertTitle] ="
+" @AlertTitle , [AlertMsg] = @AlertMsg , [AlertStartDate] = @AlertStartDate ,"
+" [AlertExpireDate] = @AlertExpireDate , [AlertType] = @AlertType ,"
+" [AlertClassLevel] = @AlertClassLevel , [AlertApps] = @AlertApps , [ActionName]"
+" = @ActionName , [ControllerName] = @ControllerName , [DateAdded] = @DateAdded"
+" , [AddedByUMSUserID] = @AddedByUMSUserID WHERE [ID] = @ID;"
+" IF @@ROWCOUNT = 0"
+" INSERT INTO [dbo].[Alerts] ( [AlertName] , [AlertTitle] , [AlertMsg] ,"
+" [AlertStartDate] , [AlertExpireDate] , [AlertType] , [AlertClassLevel] ,"
+" [AlertApps] , [ActionName] , [ControllerName] , [DateAdded] ,"
+" [AddedByUMSUserID]) VALUES ( @AlertName , @AlertTitle , @AlertMsg ,"
+" @AlertStartDate , @AlertExpireDate , @AlertType , @AlertClassLevel ,"
+" @AlertApps , @ActionName , @ControllerName , @DateAdded , @AddedByUMSUserID);";
}
}
public string CRUDDelete
{
get
{
return "DELETE FROM [dbo].[Alerts] WHERE [ID] = @ID;";
}
}
#endregion database properties
}
}
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Bravo! especially for the UPSERT part.
But it would be even more interesting if it could also generate PostgreSQL code!
|
|
|
|
|
RickZeeland wrote: Bravo! especially for the UPSERT part.
That's actually configurable - you can tell the app not to combine the insert and update parts.
RickZeeland wrote: But it would be even more interesting if it could also generate PostgreSQL code!
I'm going to leave that as an exercise for another programmer. Besides that, you can easily inherit the generated class, and override the CRUD properties to support your own kind of chaos.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Quote: support your own kind of chaos I already have enough chaos at hands thank you!
Should really try harder to work with NHibernate as that's what has been chosen as the standard where I work, but till now have been able to avoid implementing it in the projects I work on.
Also I should do some DevOppy things with Docker, but it seems to make no sense to use Docker with Windows, it's clearly a Linux thing
|
|
|
|
|
Thankfully, nobody on our team is enamoured with ORMs of any description. I can really understand the desire to have some of your more tedious code auto-magically generated, but ORMs impose to many proprietary ideas about how things should work, and how you should work with them, and it's often more tedious to find out how to get around those ideas than it is just to crank out your own code. This tool leans more towards the "crank out your own code" crowd. Even the viewmodel generator allows you to specify your own implementation of INotifyPropertyChanged and IDataErrorinfo (it provides my own implementation as a default, but the user can change it).
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I think I would get flayed if I posted that much code in the lounge.
Congratulations to you.
Real programmers use butterflies
|
|
|
|
|
Be careful what you say about JSOP, he's very dangerous
|
|
|
|
|
In American Texas, code poster flays you
|
|
|
|
|
I don't see the problem with posting the output from a code generator, as long as you don't pose a question about it in the message. At that point, you're simply showing the output of an application. If anyone gives you grief, let me know - I'll set 'em straight.
Note - I purposely chose a table that only has a few returned columns.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I don't either, personally. I appreciated your comment, as I am a fan of code generation.
Real programmers use butterflies
|
|
|
|
|
JSOP is a special case, a bit like OG, the Richards and you for that matter. People who contribute so much to the site that they have and deserve carte blanche. It is very rarely abused.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
That's fair. I try not to abuse the forum myself but I'm a weirdo and social decorum is not always my best strength, even online. Even among other developers.
Real programmers use butterflies
|
|
|
|
|
Why not an article, or even a tip, where it stays in a more permanent place than this Lounge?
|
|
|
|
|
0) I've been here for 20 years. I know how to do this.
1) I'll write/publish the article when the code is done. I started the article last May when the code was reasonably complete, but lost a crap load of the code, and stopped working on it. As stated in the original message, I decided to start working on it again this week to rewrite the code I'd lost, and was merely sharing the progress.
2) Cool your jets, Sparky.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
CrudGet*
CrudUpsert*
CrudDelete*
I was going to ask why you didn't use a MERGE for the UPSERT, but I already found out myself. Good stuff!
|
|
|
|
|
Sander Rossel wrote: I was going to ask why you didn't use a MERGE for the UPSERT, but I already found out myself.
Using the MERGE function is fraught with danger, and it's easy to do it wrong. Furthermore, a MERGE operation is usually more complex, and typically uses several of the table's columns to determine whether or not an item should be updated. There's probably no way to generate it automagically that would be suitable in more than a small handful of instances.
It is simply easier and more reliable to generate an Upsert instead.
The programmer can always extend the generated partial class and include a specific CRUDMerge property, so I think my bases are sufficiently covered. BTW, this is primary reason I'm writing this aapp - the existing tools don't create partial classes, and don't allow you to customize their implementation based on corporate requirements as far as coding style and framework component inclusion. For instance, you can specify your own implementation code for INotifyPropertyChanged, and IDataErrrorInfo interfaces in the generated viewmodel, and you can even specify the standard using statements for the model and viewmodel (although the usefulness of these would only benefit you if a given "standard" name space was removed from .Net at some point in the future).
It's a cool app, and we're going to use it at work when we start our flagship application rewrite (whenever that's allowed to happen).
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: It's a cool app, and we're going to use it at work when we start our flagship application rewrite (whenever that's allowed to happen). Good stuff!
I've been using Entity Framework Core and love it so far.
I just write my domain models, write my DB mapping and let EF sort out the rest.
Not so nice when you get breaking changes and EF just drops a column (or table) instead of renaming and that sort of stuff
The queries it generates are pretty clean overall and I've gotten a lot better at predicating what they look like based on my LINQ query
|
|
|
|
|
The company I work for would flog you for using the NOLOCK hint in your SELECT statement.
Kelly Herald
Software Developer
|
|
|
|
|
Wehave simulateous access by thousands of users and dozens of stored procs, we have to do that because our queries take a few seconds.If we don't do it, we get errors.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I decided to go for KeePass[^].
It's ugly.
But all is stored locally with high encryption, no need to connect to any server somewhere.
And even Bitwarden seems much nicer (aesthetically) I should have installed a docker container in my NAS to act as my personal server to avoid sending all my passwords into the cloud which seems too much overkill to me.
THANK YOU VERY MUCH everybody who posted an answer and a hint.
|
|
|
|
|
Joan M wrote: It's ugly.
Take that back! The interface can be considered "old school" by today's standard, but it's compact and functional. To me it's the peak usability. None of that modern big flat and empty surfaces crap taking valuable screen real estate.
Look at this crap! Something like 70% of the screen is nothing. I understand developers not caring about performance and expecting users to throw more hardware at the problem, but that does not work with monitors... I mean at some point user's room will not be large enough to fit the screen needed to display your damn application.
|
|
|
|
|