|
megaadam wrote: Does backend-Java strike you as fresh?
No, it smells. Quite badly.
|
|
|
|
|
Yea well Jörgen...
’tis my spontaneous feeling as well. But I am going to some interview next week so...
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Probably time to mention that I was thinking of Javascript, not Java.
Java doesn't reek, it merely has an unpleasant smell if you're not into it, a bit like the disinfection fluids they use at hospitals.
Some like it. I wouldn't say no to it if my current job was at a pig farm, but I would still prefer cinnamon buns. 
My company bought a startup last year, their backend is done in NodeJS. Now, that smells, and that's what I was thinking about.
The poor guys working on that pile of manure is patching the patchwork on a daily basis. Trying to refactor as they go.
It's a good thing that we don't do deadlines here.
|
|
|
|
|
Part 4 of adventure in Linux is to replace Windows 7 with a Linux NAS solution.
I installed OpenMediaVault and (as I already knew) it could see the four ntfs formatted partitions, but it couldn't do anything with them as far as monitoring for size/health. This is where the adventure started.
Because OVM takes over the box, I installed Lubuntu to make it easier to work on the drives.
My nefarious plan involved copying files from one of the drives at a time onto the 2tb drive i removed from the new Dell laptop, replace the ntfs partition with an ext4 partition, and copy the files back to the drive.
It took 2.5 hours to copy the files to the laptop drive, and I used gparted to remove the ntfs partition from the NAS drive, and re-partition/format it for ext4, but then I hit a wall. The drive's owner is root, and after some research, I discovered that I had to do sudo chown to change ownership on the drive.
After this initial setup, I can reinstall OVM, and then link my Kodi (home theater) box to it.
BTW, a number of years ago, I setup this box with FreeNAS, and it was fine until I went to update FreeNAS. The newer version of FreeNAS no longer supported NFS partitions. It pissed me off, and since I had to copy all of the ISOs all over again anyway, I installed Windows on the box. So that's where we are today.
".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
|
|
|
|
|
|
It turns out that I'm going to have to maintain a Windows VM so I can run DVDFab. There is no Linux equivalent/alternative to that application, although they did take a swing at a Linux version last year, but later abandoned the project. There was no reason cited for quitting that I could find.
".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
|
|
|
|
|
Entity Framework in agile environment - Design and Architecture Discussion Boards[^]
Was reading this thread. Just want to really know,
is there really someone who's using Code-first as the standard approach in their project?
I've been trying to do this, but somehow the team environment/people rushes towards DB first.
Even our boss is not so keen in getting to this
Is this something we should definitely aspire to achieve or it's okay to continue with DB first approach?
|
|
|
|
|
The bosses always wanted to push the application I am working on to code first. Newer parts work with EF, but there are also more than 20 year old parts that depend on stored procedures. We still need to make changes to the SPs and the data tables. One far away day, when the sun has used up most of its hydrogen and starts to cool down and collapse, we will finaly be rid of all these stored procedures and have EF and the database in a shape that will actually allow code first.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
EF without "views" and "stored procedures" is like using C# without the .NET framework classes.
EF "complements" the database engine; it doesn't "replace" it.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
That may be so, but these oldschool SPs designed to be used with DataSets, DataTables and DataRows do not have much in common with the Entity Framework.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
You're assuming every SP returns a result set; they don't.
And a "datatable row" is the equivalent of an entity.
One purpose of SP's is to execute logic on the DB server that has no business running on the client.
No SP's usually means: simplistic design; or poor design and poor performance.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Code first is fine for prototyping and knocking out quick things, but it's not suitable for production applications, IMEO.
|
|
|
|
|
Exactly. They don't tell you this in the documentation. 
|
|
|
|
|
By definition, a "production" system is past "code first" or "database first"; it's in maintenance mode; which will then probably involve both in one form or another depending on the "fixes" moving forward.
A database can have multiple data contexts.
A system can have multiple databases.
A system "enhancement" can involve adding a new database. Code first or database first?
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
What you described is a production environment, not a production system. By production system I meant an application that is intended to go live and be used in a serious business capacity.
|
|
|
|
|
No, I'm describing "systems"; "serious" ones: O&G production; Financials; MRP; etc.
And AP, AR, GL, FA ... all systems in the "bigger" Financials (system).
Nothing about "environment".
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Quote: By definition, a "production" system is .. in maintenance mode
That reads to me that you were referring to the environment. If you actually meant "serious" apps, then what you said is that by definition serious apps are in maintenance mode and that makes no sense.
That's how I read it anyway.
|
|
|
|
|
In my world, there is "new development" and "maintenance".
(Proposed) "Systems" are analyzed (existing physical and logical); designed (logical and physical); developed; tested; integrated; documented; implemented (i.e. "put into production"); then, turned over for "support and maintenance" (by the group responsible for that area).
If you're a one man show, maybe you're always "in development" and don't ever get to "turn it over".
Actually, you better be clear knowing where "development" ends and "maintenance" begins:
That's what "service contracts" are for (and that's where your long term revenue OR expense comes from).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
modified 12-Oct-18 11:38am.
|
|
|
|
|
Not quite what you are asking, but it made me think of one Norwegian author, Jens Bjørneboe:
He always started out the work on a new novel by deciding on the last word of the book. Everything in the novel should point towards the closing word.
The last word of his autobiography was to be "butterfly". He never got to complete it, though.
|
|
|
|
|
Just say no to Entity Framework.
".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 guess you should mix it, as already commented, to push out prototypes and quick showcases it's fine to go code-first. For most other stuff i'd suggest DB first.
I for my self went up with all basic data i need for the application, built up the database and stuff and then coded. But for new small things that just need a new table or field i mostly design it in code first, show it, get the changes fixed and then put it in the DB before i code the final implementation.
Rules for the FOSW ![ ^]
if(!string.IsNullOrWhiteSpace(_signature))
{
MessageBox.Show("This is my signature: " + Environment.NewLine + _signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
I usually work with dbs. So The db is already included in the virgin app/server code as a basic entity.
I also use the db for logging.
so its just natural.
It is just a part of the system. As per the remote hardware etc.
|
|
|
|
|
Code First is working fine for me in our airport management system.
Of course, I keep tight control over any changes to the model. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I prefer using DB first... it's just easier for me to design the db and then use the scaffolding to make the EF (core) classes.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
