Projekt do CV asp.net

Jaki projekt powinien umieć napisać kandydat do pierwszej pracy? Bo pewnie Hello World to za mało, a jakichś mocno skomplikowanych pewnie też będzie ciężko komuś bez zawodowego doświadczenia. Napisanie jakiego projektu z zachowaniem dobrych praktyk pozwala myśleć o pierwszej pracy? Interesuje mnie asp.net mvc.

CV programista bez doświadczenia
Osoby, które zaczynają przygodę z programowaniem, zarówno studenci jak i osoby po szkole średniej bądź w trakcie przekwalifikowania się, przeważnie nie mają czym się pochwalić w CV. Poniżej kilka wsazówek, dzieki którym nawet CV programisty bez doświadczenia zyska na wartości.

Własne projekty - zbierz wszystkie projekty jakie wykonałeś podczas nauki i wybierz te według Ciebie są najlepsze (nawet jezeli uważasz że żaden się nie nadaje i tak wybierz kilka).
Dzięki temu po pierwsze wykażesz pasję oraz chęci do programowania a po drugie pozwoli Ci się to wyróżnić na tle innych osób. Pamiętaj - nawet prosty kalkulator bądź trywialna gra na konsoli systemowej może być podstawą do rozmowy oraz pytań podczas rozmowy rekrutacyjnej początkującego progarmisty.

Jeśli nie masz projektów do pochwalenia się oto kilka pomysłów na proste aplikacje do pochwalenia się w CV:

kalkulator
gra kółko-krzyżyk
aplikacja konsolowa - sprawdzanie czy wpisany ciąg znaków jest palindromem
aplikacja konsolowa - pobieranie informacji od użytkownika oraz wypisywanie ich na ekran
prosta strona internetowa
Warto odnotować także uczestnictwo we wszelakich kołkach programistycznych bądź lokalnych grupach programistycznych.

Warto dołączyć do projektu open source - taki wpis w CV jest bardzo doceniany.

Źródło:http://skillstest.pl/cvprogramista
Myślę że to jest dobra propozycja ^^

Interesuje mnie technologia asp.net mvc.

kalkulator
gra kółko-krzyżyk
aplikacja konsolowa - sprawdzanie czy wpisany ciąg znaków jest palindromem
aplikacja konsolowa - pobieranie informacji od użytkownika oraz wypisywanie ich na ekran
prosta strona internetowa

To raczej za mało. Takie aplikacje konsolowe pisze się na drugich labach z podstaw programowania, kółko-krzyżyk na trzecich. Prosta strona internetowa to może na front i to kilka lat temu.

Według mnie możesz napisać jakiś projekt, który potem łatwo rozwijać w coś większego, nie ma problemu w wymyśleniu kolejnej funkcjonalności, zaczniesz od prostych i pójdziesz w coraz bardziej zaawansowane.
Propozycje tak na szybko:

• system zarządzania firmą spedycyjną,
• system zarządzania komunikacją miejską,
• sklep internetowy,
• wszelkiego typu wypożyczalnie,

asp.net mvc

napisz jakas prosta aplikacje do wynajmu czegos (samochodow, samolotow, komputerow) z kryterami szukania oraz zamawiania wraz z walidacja (bez transakcji finansowej po prostu, ze taka jest funkcjoanlnosc jest).

Do tego testy integracyjne + jednostkowe.

Napisz tak aplikacje by byla mozliwosc latwej rozbudowy (dodaj DI, pomysl nad Repository Pattern)

Jezeli fullstack: skup sie by jakos to wyglado ze strony wizualnej i ze strony logicznej
jezeli backend: skup sie na na plikach .cs a frontend sobie wygeneruj jakis domyslny

Jak się szuka pomysłu na pierwszy projekt, to ciężko coś sensownego wymyślić, a jak już się go robi, to nagle pojawiają się pomysły na jeszcze ciekawsze projekty. Możesz zrobić aplikację webową, która robi to samo, co robi aplikacja, której często używasz i której działanie i reguły biznesowe dobrze znasz. Np. jeśli jesteś pracownikiem help desku, to napisz system do zarządzania ticketami, a jeśli pracujesz na magazynie, to zrób system do zarządzania magazynem. Jeśli nie masz pomysłu, bo nigdy nie pracowałeś lub nie używałeś komputera w pracy, ale np. lubisz czytać książki, to zrób system do katalogowania książek i ich oceniania, komentowania, recenzowania, wyszukiwania itp.

Zdarza mi się oceniać CV'ki ludzi, wolę zobaczyć jedną-dwie proste aplikację, które jest na błahy temat, ale dobrze napisaną (testy, wzorce) niż masą nic nie wartych aplikacji.
Ważne jest żeby mieć dowód że się o czym mówi, a że potem na rozmowie kw gość mówi o różnych wzorcach ale brzmi to jakby się tego wykuł na egzamin.

Slepiec napisał(a):

Zdarza mi się oceniać CV'ki ludzi, wolę zobaczyć jedną-dwie proste aplikację, które jest na błahy temat, ale dobrze napisaną (testy, wzorce) niż masą nic nie wartych aplikacji.
Ważne jest żeby mieć dowód że się o czym mówi, a że potem na rozmowie kw gość mówi o różnych wzorcach ale brzmi to jakby się tego wykuł na egzamin.

dokładnie i to jest właśnie to co napisałem wyżej ^^

Do tego warto taką aplikację wrzucić na githuba, to pozwoli już na etapie przeglądania CV sprawdzić co już umiesz i łatwiej jest wtedy przy późniejszej rozmowie. Do tego przy okazji poćwiszysz sobie gita, którego znajomość przyda się później w pracy.

Przy okazji z czasem możesz kogoś poprosić o jakiś feedback odnośnie kodu aplikacji.

Jak rozbudowana powinna być aplikacja np. Sklepu internetowego, aby nie była ona zbyt prosta?

Czarny Baran napisał(a):

Jak rozbudowana powinna być aplikacja np. Sklepu internetowego, aby nie była ona zbyt prosta?

Myślę, że najlepiej jak byś na początku bardziej skupil się na tym co jest w kodzie aplikacji, a nie na samych funkcjonalnościach. Ważniejsze jest użycie różnych mechanizmów i znajomość koncepcji, co może bardziej zaprocentować. Dodatkowo przy mniejszej ilości funkcjonalności łatwiej będzie dodawać kolejne mechanizmy, bo mniej kodu będziesz musiał modyfikować. Na początku skup się na zarządzaniu na przykład kategoriami produktów oraz produktami (aby mieć w modelu danych relację jeden do wielu).

Tworząc swoją aplikację wykorzystaj takie rzeczy jak:

• Podziel aplikację na warsty/projekty: domenowa (obiekty, które reprezentują model danych i na nich będzie tworzony schemat bazy danych), logika biznesowa aplikacji, wartwa dostępu do danych z repozytoriami, obiektem kontektowym Entity Framework, migracjami oraz sam projekt aplikacji webowej
• Wykorzystaj viewmodele (zamiast modelu z projektu domenowego) do przekazywania danych z kontrolera do widoku (aby przekazywać dodatkowa dane do widoku - lista dostępnych kategorii w widoku dodania nowego produktu - aby nie używać ViewData oraz ViewBag)
• Wykorzystaj Automappera (https://automapper.org/), aby mapować automatycznie viewmodele na modele i na odwrót
• Dodaj walidację z wykorzystaniem czegoś więcej niż data annotations - polecam użycie Fluent Validation (https://github.com/JeremySkinner/FluentValidation) - ostatnio na swoim blogu napisałem kilka postów na temat użycia tej biblioteki: https://plawgo.pl/2018/03/09/fluent-validation/ oraz https://plawgo.pl/2018/04/10/integracja-fluent-validation-z-asp-net-mvc/
• Przy tworzeniu zależności między klasami wykorzystaj inversion of control (czyli w dużym skrócie bazuj na interfejsach) i następnie użyj jakiegoś kontenera dependency injection do wstrzykiwania zależności do klas - możesz użyć autofac - https://autofac.org/
• Dodaj jaki mechamizm generowania danych startowych do bazy - możesz użyć np. nbuidler (https://github.com/nbuilder/nbuilder) and faker.net (https://github.com/oriches/faker-cs) - https://plawgo.pl/2018/03/02/nbuilder-oraz-faker-net/
• Zrezygnuj z używania stringów jako nazw akcji/widoków i użyj T4MVC, który Ci wszystko ładnie wygeneruje - https://github.com/T4MVC/T4MVC
• Dodaj jakieś narzędzia do diagnozowania aplikacji - glimpse (http://getglimpse.com/), elmah (https://elmah.github.io/), miniprofiler (https://miniprofiler.com/) - u mnie na blog znajdzie parę wpisów o tych bibliotekach
• Dodaj automatyczne testy do kodu - testy jednostkowe, integracyjne oraz interfejsy użytkownika np. w selenium
• Z czasem możesz dodać na przykłąd wysyłkę maila z wykorzystaniem biblioteki postal (http://aboutcode.net/postal/) i najlepiej z wykorzystaniem jakiś kolejek z ponawianiem wysyłki, gdy się nie udało - możesz użyć do tego hangfire - https://www.hangfire.io/

Jak sam widzisz jest tego dużo i znajomość tych rzeczy dużo lepiej zaprocentuje nawet w bardzo prosty projekcie od strony funkcjonalności niż rozbudowany projekt ale z słabym kodem w środku. Do tego jak wcześniej napisałem wrzucaj kod na githuba, działaj i pytaj się innych co jeszcze ciekawgo można do niego dorzucić :)

daniel.plawgo napisał(a):

• Podziel aplikację na warsty/projekty: domenowa (obiekty, które reprezentują model danych i na nich będzie tworzony schemat bazy danych)

Warstwa domenowa to nie jest model danych tylko model biznesowy.

wartwa dostępu do danych z repozytoriami

Repozytoria to nie jest element warstwy dostępu do danych. To, co mu doradzasz, to DAO, a nie żadne repozytoria.

• Przy tworzeniu zależności między klasami wykorzystaj inversion of control (czyli w dużym skrócie bazuj na interfejsach) i następnie użyj jakiegoś kontenera dependency injection do wstrzykiwania zależności do klas - możesz użyć autofac - https://autofac.org/

W IoC nie chodzi o żadne interfejsy, a DI to tylko jeden z przykładów IoC, i też nie potrzebuje żadnych intefejsów.
Tworzenie interfejsów z jedną implementacją tylko w celu wstrzykiwania zależności to code smell.

• Zrezygnuj z używania stringów jako nazw akcji/widoków i użyj T4MVC, który Ci wszystko ładnie wygeneruje - https://github.com/T4MVC/T4MVC

Czy używanie dodatkowej biblioteki w celu, który teraz można załatwić na poziomie języka (operatorem nameof) niesie jakąś korzyść?

Z resztą rzeczy się zgadzam, tylko nie jestem pewien czy zrobienie tego wszystkiego faktycznie jest potrzebne do zdobycia pierwszej pracy. Zwłaszcza, że niedoświadczonemu trudno będzie to zrobić dobrze.

somekind napisał(a):

daniel.plawgo napisał(a):

• Podziel aplikację na warsty/projekty: domenowa (obiekty, które reprezentują model danych i na nich będzie tworzony schemat bazy danych)

Warstwa domenowa to nie jest model danych tylko model biznesowy.

wartwa dostępu do danych z repozytoriami

Repozytoria to nie jest element warstwy dostępu do danych. To, co mu doradzasz, to DAO, a nie żadne repozytoria.

• Przy tworzeniu zależności między klasami wykorzystaj inversion of control (czyli w dużym skrócie bazuj na interfejsach) i następnie użyj jakiegoś kontenera dependency injection do wstrzykiwania zależności do klas - możesz użyć autofac - https://autofac.org/

W IoC nie chodzi o żadne interfejsy, a DI to tylko jeden z przykładów IoC, i też nie potrzebuje żadnych intefejsów.
Tworzenie interfejsów z jedną implementacją tylko w celu wstrzykiwania zależności to code smell.

• Zrezygnuj z używania stringów jako nazw akcji/widoków i użyj T4MVC, który Ci wszystko ładnie wygeneruje - https://github.com/T4MVC/T4MVC

Czy używanie dodatkowej biblioteki w celu, który teraz można załatwić na poziomie języka (operatorem nameof) niesie jakąś korzyść?

Z resztą rzeczy się zgadzam, tylko nie jestem pewien czy zrobienie tego wszystkiego faktycznie jest potrzebne do zdobycia pierwszej pracy. Zwłaszcza, że niedoświadczonemu trudno będzie to zrobić dobrze.

Hej,

dzięki za komentarz, faktycznie masz rację, niestety w kilku miejsach użyłem zbyt dużego skróty myślowego, aby zasygnalizować tematy, które warto poznać bardziej, a nie koniecznie definicja danego pojęcia - Jeszcze raz dzięk!

Co do nameof, to fakt można tego użyć w przypadku nazw akcji ale chyba (akurat z przyzwyczajenia korzystam z T4MVC, więc nie jest w 100% pewien) w przypadku nazwa kontrolerów, widoków, czy zasobów (np. ścieżka do pliku js) to już nameof nie będzie takie proste w użyciu lub w ogóle możliwe?

Oczywiście nie mam na myśli, że te wszystkie rzeczy są wymagane do zdobycia pierwszej pracy. Bardziej myślę, że lepiej zrobić projekt, który będzie miał tylko kilka widoków i spróbować poznać choć część z wymienionych pojęć, niż naklepać dziesiątki widoków, gdzie cały kod aplikacji jest tylko w akcjach kontrolerów, jak to często jest pokazywane w podstawowych materiałach z ASP.NET MVC.

patrykkxdd napisał:

CV programista bez doświadczenia

Bardzo nie lubię stwierdzania "Programista bez doświadczenia" tylko dlatego, że nie ma doświadczenia w korpo. Co niektórzy siedzą w po nocach po pracy albo pracują na pół etatu, byle programować i często też mają komercyjne projekty, robione na lewo bez umowy. Tacy ludzie mają dla mnie wartość, a nie bobki z ukończonymi studiami, dla których praca to tylko czas, który trzeba odbębnić i wsiąść kasę. Picują się z CV a najczęściej nie potrafią odpowiedzieć na pytanie, Czym się różnie DI od IOC. Co mnie w sumie nie dziwi, bo co niektórzy specjaliści nawet na swoich konferencjach nie odróżniają jednego od drugiego.

Nie, ważne co napiszesz, masz pokazać, że rozumiesz, co robisz i robisz to dobrze.

somekind:

W IoC nie chodzi o żadne interfejsy, a DI to tylko jeden z przykładów IoC, i też nie potrzebuje żadnych intefejsów.
Tworzenie interfejsów z jedną implementacją tylko w celu wstrzykiwania zależności to code smell.

No chyba, że używasz interceptorów do tej jednej klasy :)

daniel.plawgo napisał(a):

Co do nameof, to fakt można tego użyć w przypadku nazw akcji ale chyba (akurat z przyzwyczajenia korzystam z T4MVC, więc nie jest w 100% pewien) w przypadku nazwa kontrolerów, widoków, czy zasobów (np. ścieżka do pliku js) to już nameof nie będzie takie proste w użyciu lub w ogóle możliwe?

nameof pomoże przy elementach kodu, czyli w tym przypadku nazwach kontrolerów i akcji. Do zasobów to nic nie da, do widoków (jeśli nazywają się inaczej niż akcje) też nie, więc biblioteka, którą proponujesz wydaje się być lepszym rozwiązaniem. W sumie, to nie znałem jej wcześniej, dzięki, bo i ja się czegoś nauczyłem dzięki temu.

Bardziej myślę, że lepiej zrobić projekt, który będzie miał tylko kilka widoków i spróbować poznać choć część z wymienionych pojęć, niż naklepać dziesiątki widoków, gdzie cały kod aplikacji jest tylko w akcjach kontrolerów, jak to często jest pokazywane w podstawowych materiałach z ASP.NET MVC.

Jasne, tu pełna zgoda.

Skromny Kret napisał(a):

No chyba, że używasz interceptorów do tej jednej klasy :)

Też nie. :) Wystarczy aby metoda była wirtualna.

Też nie. :) Wystarczy aby metoda była wirtualna.

A jeśli klasa i metoda jest generyczna ?

Nie widzę problemu, metody generyczne w klasach generycznych też mogą być wirtualne.

somekind napisał(a):

Nie widzę problemu, metody generyczne w klasach generycznych też mogą być wirtualne.

Może ręcznie zapomocą emisji refleksji, ale z tego, co wiem to ani Autofa ani Windsor. Tego nie oferuje. Albo klasa z wirtualnymi metodami, albo klasa generyczna z interfejsem. Jeśli chcesz używać aspektów.

A spróbuj zaimplementować klasę generyczną z wirtualnymi metodami i interoceptorem na Autofacu, mnie się nie udało.

W swoich projektach zazwyczaj robię to tak:

using Autofac;
using Autofac.Extras.DynamicProxy;
using Castle.DynamicProxy;
using System;
using System.Collections.Generic;
using System.Globalization;
using System.Linq;
using System.Reflection;
using System.Text;

namespace IocTest
{
    class Program
    {
        static void Main(string[] args)
        {
            IContainer container = BootstrapContainer();

            var sbService = container.Resolve<SBService>();
            var ciService = container.Resolve<CIService>();

            var list1 = sbService.MakeList(666);
            var list2 = ciService.MakeList("lalala");

            Console.WriteLine("Done!");
            Console.ReadLine();
        }

        private static IContainer BootstrapContainer()
        {
            var builder = new ContainerBuilder();
            builder.RegisterType<CallLoggingInterceptor>();
            builder.RegisterAssemblyTypes(Assembly.GetExecutingAssembly())
                .Where(t => t.Name.EndsWith("Service"))
                .AsSelf()
                .EnableClassInterceptors()
                .InterceptedBy(typeof(CallLoggingInterceptor));

            return builder.Build();
        }
    }

    class CallLoggingInterceptor : IInterceptor
    {
        public void Intercept(IInvocation invocation)
        {
            string methodName = $"{invocation.TargetType.Name}.{invocation.Method.Name}";
            Console.WriteLine($"TransactionManagingInterceptor executes method: {methodName}");

            invocation.Proceed();
        }
    }

    public class SBService : GenericService<StringBuilder>
    {
    }

    public class CIService : GenericService<CultureInfo>
    {
    }

    public class GenericService<TType>
    {
        public virtual List<TItem> MakeList<TItem>(TItem value)
        {
            return new List<TItem> { value };
        }
    }
}

A jeśli chcesz zrobić coś takiego ?

var genericService = container.Resolve<GenericService<StringBuilder>>();

    public class ConcreteControler : ABaseControler<string>
    {
        public ConcreteControler(GenericService<string> service) : base(service)
        {
        }
    }

    public abstract class ABaseControler<TType>
    {
        private readonly GenericService<TType> service;

        public ABaseControler(GenericService<TType> service)
        {
            this.service = service;
        }

        public void DoSomekindsOftThings(TType value)
        {
            var list =  service.MakeList(value);

            list.OrderBy(x => x);
        }
    }

    public class GenericService<TType>
    {
        public virtual List<TItem> MakeList<TItem>(TItem value)
        {
            return new List<TItem> { value };
        }
    }

Nie da się bez interface.