반응형
반응형

Classic ASP에서 GUID 생성 방법

 

Classic ASP에서 브라우저에 접속한 사용자의 고유한 키 값을 생성하기 위해 주로 사용하는 방법은 **GUID(Globally Unique Identifier)**를 생성하는 것입니다. GUID는 전 세계에서 유일한 값을 가지도록 설계된 128비트 값으로, 사용자의 고유 세션이나 식별자를 만들 때 유용합니다.

Classic ASP에서 GUID 생성 방법

ASP에서 GUID를 생성하는 가장 쉬운 방법은 Scriptlet.TypeLib을 사용하여 GUID를 만드는 것입니다. 다음은 Classic ASP에서 GUID를 생성하여 고유 키를 얻는 코드입니다.

<%
Function GenerateGUID()
    Dim objTypeLib
    Set objTypeLib = CreateObject("Scriptlet.TypeLib")
    GenerateGUID = objTypeLib.Guid
    Set objTypeLib = Nothing
End Function

' 생성된 GUID 호출 예제
Dim uniqueKey
uniqueKey = GenerateGUID()

' 브라우저에 출력
Response.Write "Generated Unique Key: " & uniqueKey
%>

설명

  1. CreateObject("Scriptlet.TypeLib"): Scriptlet.TypeLib 객체는 GUID를 생성할 수 있는 COM(Component Object Model) 객체입니다.
  2. GenerateGUID = objTypeLib.Guid: .Guid 속성을 호출하면 GUID 값을 반환합니다. 이 값은 일반적으로 { }로 감싸진 문자열로 출력됩니다.
  3. 고유한 키 사용: 생성된 uniqueKey를 쿠키, 세션 변수 등에 저장하여 사용자 식별 등에 사용할 수 있습니다.

고유 키 생성 방법의 활용

  • 세션 관리: 로그인 세션 관리에 활용할 수 있습니다.
  • 추적 및 분석: 방문자를 추적하거나 분석할 때 유용합니다.
  • 데이터베이스 키: 사용자별 고유한 데이터베이스 키로 사용할 수 있습니다.

이 방법을 사용하면 Classic ASP에서 손쉽게 고유한 키 값을 생성하여 사용할 수 있습니다.

반응형
반응형

https://blog.stackademic.com/frontend-masters-feature-sliced-design-fsd-pattern-81416088b006

 

Feature-Sliced Design (FSD) Pattern

Imagine a delicious pizza as your complex project. To understand how feature slicing works, let’s break it down slice by slice: easy to manage and delicious (to maintain)! 🍕

I will repeat what I said in my previous medium stories. This will be a long (because why not 😇) and maybe a little difficult to understand article. But once you read it and understand it perfectly, you will now be a 10x frontend developer. 😎 Let’s take your coffee. ☕️ If you don’t drink enough coffee, it will take you longer to become a 10x developer. 😅

 

I like to simplify web and mobile applications by dividing them into smaller parts called feature sets. Each feature set has its own user interface, business logic, and data layer, making it easier to handle. This method, called Feature-Sliced Design (FSD), shares advantages with component-based approaches. What stands out to me about FSD is its ability to break down web and mobile applications into more manageable pieces, especially focusing on user-centric features.

 

Structure

FSD methodology is built on three abstraction levels: layers, slices, and segments.

Layers and Slices

Imagine your app as a delicious pizza. 🍕 (As a developer working at Domino’s, it is my natural right to use the pizza analogy. 😎)

1. Shared Layer (The Pantry):

  • Ingredients for everyone: Holds reusable components, utilities, hooks, and services that multiple slices can access. (Think of it as the shared kitchen where everyone can grab common ingredients and tools.)
  • Examples:
    - 
    Common UI elements like buttons, forms, modals and navigation bars (think of them as pre-cut veggies and cheese)
    - Utility functions for data formatting or validation (like a sharp pizza cutter)
    - Global state management solutions like Redux, Zustand, Tanstack Query (the recipe book for consistency)

2. Processes Layer (The Kitchen Staff):

  • The hardworking chefs: Handles background tasks and data fetching, keeping the pizza kitchen running smoothly. (Think of them as the pizza chefs who prepare the dough, sauce, and toppings, and coordinate the baking process.)
  • Examples:
    - 
    Fetching pizza orders from the online system
    - Sending notifications when pizzas are ready
    - Syncing data with the delivery drivers

3. Features Layer (The Pizza Slices):

  • Independent and self-contained: Each slice encapsulates a specific feature, with its own UI, logic, and data, like individual pizza slices with their toppings.
  • Examples:
    - “Order Pizza” slice:
     Handles pizza selection, customization, and checkout (pepperoni, mushrooms, extra cheese, sucuk -sausage- you name it!)
    - “Track Order” slice: Displays order status and estimated delivery time (like a pizza tracker)
    - “Review Pizza” slice: Allows customers to rate and comment on their experience (a feedback form for the chef)

4. App Layer (The Pizza Chef):

  • The head chef: Oversees the entire pizza-making operation, deciding which slices to bake and how to present them to customers. (Think of it as the master chef who designs the menu, creates new recipes, and ensures each pizza is cooked to perfection.)

5. Pages Layer (The Pizza Display):

  • Arranges the slices: Composes slices into meaningful page layouts, like arranging pizza slices on a platter or delivery carton box.
  • Examples:
    - Homepage:
     Combines “Featured Pizzas” and “Order History” slices
    - My Account: Includes “Personal Information” and “Order Preferences” slices

6. Widgets Layer (The Spices):

  • Optional flavor enhancers: Small, reusable UI components that can be sprinkled across slices or pages/screens, like adding extra seasoning to your pizza.
  • Examples:
    - 
    Search bar (for finding your favorite pizza quickly)
    - User notification panel (alerting you when your pizza is ready)
    - Modal dialogs (for special requests or confirmations)

5. Entities Layer (The Raw Ingredients):

  • Building blocks of data: Represents core business entities, like the flour, yeast, and toppings in a pizza.
  • Examples:
    - 
    User entity (storing customer details)
    - Pizza entity (defining pizza types and ingredients)
    - Order entity (tracking order information)

Key points to remember:

  • Each layer has a clear responsibility and dependency direction.
  • Slices can communicate with each other using well-defined contracts, like pizza slices sharing a common crust.
  • The goal is to create modular, independent, and easily testable slices, making your “pizza” codebase more manageable and delicious!

Additional pizza analogy notes:

  • The kitchen staff (processes) work behind the scenes, preparing ingredients and ensuring a smooth pizza-making process.
  • The pizza chef (app) is the mastermind, orchestrating the creation of different pizzas (features) and deciding how to serve them up (pages).
  • The raw ingredients (entities) are essential for any pizza, but they’re not always visible to the customer — they’re the foundation that makes everything else possible.

Segments (The Toppings):

  • The ingredients within a slice: While a slice is a complete feature, it’s often made up of smaller parts, called segments. These are like the individual toppings that make up a pizza slice.
  • Focused on specific tasks: Each segment has a clear responsibility within its slice, like handling a particular UI element, data operation, or piece of logic.
  • Examples:
  • Within the “Order Pizza” slice:
    - “Pizza Menu” segment:
     Displays available pizza options and prices.
    - “Topping Selector” segment: Allows customers to choose their desired toppings.
    - “Checkout Form” segment: Collects payment and delivery information.

With a more React way:

Each slice is split into one or more of the following segments:

  • ui/: User Interface components and UI related logic
  • model/: Business logic (store, actions, effects, reducers, etc.)
  • lib/: Infrastructure logic (utils/helpers)
  • config/: Local configuration (constants, enums, meta information)
  • api/: Logic of API requests (api instances, requests, etc.)

Key points to remember:

  • Slices are larger, self-contained features, while segments are smaller, focused parts within a slice.
  • Each slice can have multiple segments, just like a pizza slice can have various toppings.
  • The goal is to create well-organized, modular code that’s easy to understand, develop, and maintain — like making a pizza with beautifully arranged toppings, each adding its unique flavor to the whole pie!
 

How about exemplifying what we have read so far in code?

1. Folder Structure (The Pizza Kitchen Organization):

2. Order Pizza Slice (The Extravaganzza):

// features/order-pizza/slice.tsx
import React from 'react';

interface OrderPizzaSliceProps {
  // ... slice props
}

const OrderPizzaSlice: React.FC<OrderPizzaSliceProps> = ({ /* ...props */ }) => {
  // ... slice logic and state management

  return (
    <div>
      <PizzaMenu />
      <ToppingSelector />
      <CheckoutForm />
    </div>
  );
};

export default OrderPizzaSlice;

3. Pizza Menu Segment (The Dough Base):

// features/order-pizza/components/PizzaMenu.tsx
import React from 'react';

interface PizzaMenuProps {
  // ... pizza options
}

const PizzaMenu: React.FC<PizzaMenuProps> = ({ /* ...props */ }) => {
  // ... fetch pizza options and display them

  return (
    <ul>
      {/* List of pizza options */}
    </ul>
  );
};

export default PizzaMenu;

4. Homepage (The Pizza Display Counter):

Feature-Sliced Design (FSD) is like slicing that pizza into neat, individual pieces, each with its own toppings and flavor. Here’s the good and not-so-good of this approach:

// pages/HomePage.tsx
import React from 'react';
import OrderPizzaSlice from '../features/order-pizza/slice';

const HomePage: React.FC = () => {
  return (
    <div>
      <h1>Welcome to Domino's Pizza!</h1>
      <OrderPizzaSlice />
    </div>
  );
};

export default HomePage;

Key takeaways from the code:

  • Clear folder structure: Each slice has its own folder, keeping its components and logic organized.
  • Independent slices: Each slice can be developed and tested independently, like a self-contained pizza.
  • Reusable components: Shared components (buttons, inputs, etc.) can be used across slices for consistency and efficiency.
  • Composition within pages: Pages combine slices to create meaningful layouts, like arranging pizza slices on a platter.

Remember: This is a simplified example. Real-world FSD involves more complex state management, data fetching, and communication between slices. However, this example demonstrates the core principles of organizing React apps using FSD.

The good stuff (slices):🍕

  • Easy to manage: Like separate pizza slices, each feature is self-contained, making code easier to understand, fix, and update. No more domino effect when changing one part!
  • Scales like crazy: Need more features? Just add more slices! FSD lets your app grow gracefully, adapting to new needs like adding pepperoni to your veggie delight.
  • Faster cooking (development): Different teams can work on separate slices at the same time, speeding up development like having multiple chefs making pizzas.
  • Clear ownership: Each slice has a designated “pizzaiolo,” making developers responsible for its quality and performance, similar to how each chef takes pride in their creation.
  • Testing made simple: Testing becomes like checking each slice for doneness, making it more focused and efficient.

The not-so-good stuff (crusts):👎🏻

  • Trickier planning: Slices need to work together seamlessly, like ensuring the cheese doesn’t spill over when joining them. Careful planning and communication are key to avoiding a pizza mess.
  • Learning curve: Newcomers might be initially confused by the distributed nature of the “pizza,” like figuring out where to find the pineapple chunks. Good documentation is essential to help them navigate.
  • Extra effort for teamwork: Ensuring communication and smooth connections between slices takes time and attention, like coordinating the chefs to build the perfect pizza together.
  • Potential redundancy: Sometimes, two slices might have similar ingredients, like having both mozzarella and ricotta. Careful planning and shared resources can help avoid unnecessary duplication.
  • Limited tools: FSD is still relatively new, so finding tools specifically designed for it might be like searching for a pizza cutter shaped like a unicorn. It might require some extra effort at first.

The decision:

FSD is like a great strategy for large and complex apps, but it’s not a one-size-fits-all recipe. Consider your project’s size, team, and development environment before diving in. Remember, even the most delicious pizza can be tricky to make if you don’t have the right skills and ingredients!

반응형
반응형

[HTML] sns 용 META tag

 

 

반응형
반응형

[Chrome] 크롬 브라우저의 읽기 모드

 

크롬의 비밀 병기, 읽기 모드를 활성화하는 방법

이상한 일이지만 구글은 거의 2개월 전인 지난 3월에 새로운 읽기 모드를 발표하고도 한동안 조용했다. 읽기 모드를 포함한 크롬 버전이 아직 전체 대중에게 공개되지 않아 대다수 사용자는 아직 정식 배포를 기다려야만 한다. 

현재 대다수의 데스크톱 운영체제에서는 5월 30일에, 크롬북에서는 6월 6일에 새로운 크롬 버전이 전 세계에 출시될 예정이다.

하지만 이미 2개월을 기다린 상황에서 인내심을 더 내기는 쉽지 않다. 어떤 PC에서든 크롬 읽기 모드를 바로 사용하는 방법을 알아보자.
 

  • PC에서 크롬을 연다.
  • 기대를 품고 기다린다.
  • 브라우저의 주소창에 chrome:flags를 입력한다.
  • 검색창에서 reading mode를 입력한다.
  • Reading mode라는 줄 옆에 상자를 클릭하고 설정을 기본값에서 활성화(Enabled)로 바꾼다.
  • 화면 하단 파란색의 다시 시작 버튼을 클릭한다. 
  • 이제 완료됐다. 정말 쉬운 절차다.


이제 크롬을 다시 시작하고 새로운 읽기 모드를 사용하는 방법을 알아보자.
 

  • 텍스트가 많은 기사 페이지를 연다.
  • 크롬 오른쪽 상단의 작은 사이드패널 아이콘을 찾는다. 오른쪽에 어두운 막대가 있는 상자로, 검은색 퍼즐 조각과 사용자 프로필 아이콘 사이에 있다. 
  • 읽기 모드 아이콘을 클릭한다.
  • 오른쪽에 패널이 나타나면 맨 위의 읽기 목록이라는 드롭다운 메뉴를 클릭한다.
  • 맨 아래에 있을 읽기 모드를 선택한다.


이제 오른쪽 패널에서는 걸리적거리는 광고나 귀찮은 방해물 없이 깔끔하게 텍스트로만 이루어진 웹페이지가 나타날 것이다.
 

ⓒ ITWorld
그러나 기뻐하기 전에 먼저 읽기 패널의 중요한 기능 몇 가지를 알아보자. 
 

  • 우선 패널과 메인 웹페이지 영역 사이의 선 위에 마우스를 올리고 분할선을 왼쪽으로 드래그하면 패널을 더 넓게 만들 수 있다.

 

ⓒ ITWorld 

  • 두번째로 패널 상단에 있는 표준 글꼴(Standard font)을 클릭하면 여러 가지 글꼴로 바꿀 수 있다.

 

ⓒ ITWorld 

  • 마지막으로 텍스트 크기와 함께 색상, 줄 간격, 글자 간격을 조정하면 같은 영역의 다른 옵션과 어울리도록 웹페이지를 맞춤화할 수 있다.

 

ⓒ ITWorld
이것이 전부다. 이제 보고 싶지 않은 것을 보지 않을 수 있고, 죄책감을 느끼지도 않는 방식으로 모든 텍스트를 읽을 수 있다. 클릭 한 번으로 할 수 있는 일이다.

구글 크롬의 읽기 모드 패널은 현재 안드로이드 버전에서는 사용할 수 없다. 그러나 불편을 감수할 필요는 없다. 안드로이드에는 훨씬 인상적인 자체 읽기 모드 설정이 있기 때문이다. 크롬뿐 아니라 모든 휴대폰 앱에서 작동하고, 텍스트 음성 변환도 할 수 있어 모든 기사를 어디서든 사용자 맞춤형 팟캐스트처럼 들을 수도 있다.

원문보기:
https://www.itworld.co.kr/howto/292435#csidxd83d1fbd53ee766a046529e6600dd42 

반응형
반응형

https://medium.com/@PurpleGreenLemon/php-isnt-that-bad-so-why-the-hate-c7b374b87ee4

 

PHP isn’t that bad, so why the hate?

Because it’s currently 77% of the internet right now

medium.com

PHP는 진화하고 레벨을 올리느라 바빴지만 우리가 사용하는 도구도 마찬가지입니다. 다른 활성 생태계와 마찬가지로 PHP는 끊임없는 개발로 가득 차 있기 때문입니다.

실제로 2023년 개발자 설문조사에 따르면 PHP 개발자의 64.8%가 정기적으로 프레임워크를 사용하는 것으로 나타났습니다. 모든 PHP 개발자의 절반 이상이 이러한 도구를 신뢰하고 있습니다!

그렇다면 왜 그렇게 인기가 있습니까? 글쎄, 몇 가지 큰 선수를 살펴 보겠습니다.

  • Laravel : 이것은 PHP 프레임워크의 수퍼맨입니다. 2023년 중반 현재 GitHub 에서 60,000개 이상의 별표를 받은 현재 가장 인기 있는 PHP 프레임워크입니다Laravel의 명성은 우아한 구문과 개발 속도입니다. ORM, 라우팅, 보안, Blade라는 놀라운 템플릿 엔진 등이 있습니다. Laravel은 PHP의 많은 단점을 해결하여 안전하고 유지 관리 가능한 PHP 코드를 더 쉽고 빠르게 작성할 수 있도록 합니다.
  • Symfony : Symfony는 PHP 프레임워크의 배트맨과 같습니다. 한동안 사용되어 왔으며 매우 유연하며 많은 대규모 웹 사이트 및 응용 프로그램에서 사용됩니다. 재사용 가능한 PHP 라이브러리를 사용하여 양식 생성, 개체 구성, 라우팅, 인증 등과 같은 작업을 완료할 수 있습니다. Symfony는 GitHub 에서 25,000개 이상의 별을 보유하고있으며 안정성과 수명으로 유명합니다.
  • CodeIgniter : CodeIgniter는 가볍고 설치가 간단하므로 슈퍼 히어로 비교의 플래시입니다. 모든 기능을 갖춘 웹 애플리케이션을 만들기 위해 간단하고 우아한 툴킷이 필요한 개발자에게 적합합니다. 2023년 현재 GitHub 에서 19,000개 이상의 별을 자랑합니다 .

이러한 프레임워크와 Yii , CakePHP  Zend Framework 와 같은 다른 프레임워크는 모두 PHP를 작업하기에 더 즐겁고 생산적인 언어로 만드는 데 기여했습니다. 그들은 좋은 코딩 관행을 시행하고, 재사용 가능한 코드를 제공하고, 프로그래밍의 반복적인 부분을 많이 처리하여 재미있는 일에 집중할 수 있도록 합니다. 요컨대, 그들은 당신의 PHP 생활을 훨씬 더 좋게 만듭니다.

오늘의 PHP: 평판, 현실 및 미래 가능성

PHP의 명성에 관해서는 험난한 여정이었습니다.

"프로그래밍의 핵심"에서 "웹 개발의 다크호스"가 되기까지 PHP의 여정은 헐리우드의 약자 이야기에 불과합니다. 하지만 기억하세요. 헐리우드가 좋은 보상을 좋아하는 것처럼 프로그래밍 세계도 마찬가지입니다.

따라서 몇 가지 신화를 없애자.

오해 #1: PHP는 구식이다.

그렇게 빠르지 않아, 친구! PHP 8의 도입으로 언어는 장갑을 끊는 것과는 거리가 멀다는 것을 보여주었습니다. 사실, 그것은 단지 따뜻해지고 있습니다. PHP는 여기에 있으며 동시대 제품과 경쟁할 수 있는 현대적인 기능으로 상당한 근육을 갖추고 있습니다.

오해 #2: PHP는 느리다.

옛날 옛적에 아마도. 그러나 오늘? 절대적으로하지. PHP 7 이후의 속도 향상은 엄청났습니다. 벤치 마크 테스트는 이전 버전보다 최대 3배 빠른 PHP 8 실행 스크립트를 보여줍니다. 따라서 PHP가 느리다고 말하는 사람이 있으면 캘린더를 확인하도록 요청하세요. 우리는 더 이상 2009년이 아닙니다!

신화 #3: PHP는 안전하지 않습니다.

모든 언어는 잘못 사용하면 안전하지 않습니다. 신뢰할 수 있는 프레임워크 사용을 포함하여 PHP 개발의 최신 모범 사례를 통해 PHP는 다른 언어만큼 안전할 수 있습니다. 구부러진 못에 대해 망치를 탓하지 마십시오!

PHP에 대한 보다 공정한 평가를 위한 간청

PHP는 그렇게 나쁘지 않습니다 .

그러나 농담과 비판의 대상이 되었던 PHP가 더 이상 PHP가 아니라는 점을 인식하는 것도 중요합니다 .

수년에 걸쳐 PHP는 성숙해졌습니다. 겸손한 시작에서 웹의 거의 80%를 지원하는 수준으로 성장했습니다. 과거의 비판을 해결하고 다른 최신 프로그래밍 언어와 정면으로 맞서는 기능을 도입했습니다.

다른 언어와 마찬가지로 PHP도 만병통치약이 아닙니다.

단점, 장점 및 단점이 있습니다. 그러나 이제 오래된 밈을 뒤로 할 때입니다. 다음에 웹 개발 프로젝트에 착수할 때 과거의 명성에 따라 PHP를 할인하지 마십시오.

PHP에 공정한 기회를 주고 현재 장점에 대해 평가하면 PHP 팬이 될 수 있습니다.

PHP 커뮤니티에서 말했듯 이 방 안의 코끼리가 아니라 ElePHPants 에 관한 것입니다.

따라서 조롱에도 불구하고 웹을 더 나은 곳으로 만들기 위한 사명을 지속적으로 적용하고 개선하고 지속한 이 언어의 탄력성을 축하합시다.

반응형
반응형

[HTML] details  summary , jquery로 open 제어

 

<details>

HTML <details> 요소는 "열림" 상태일 때만 내부 정보를 보여주는 정보 공개 위젯을 생성합니다. 요약이나 레이블은 <summary> 요소를 통해 제공할 수 있습니다.

정보 공개 위젯은 보통 레이블 옆의 작은 삼각형이 돌아가면서 열림/닫힘 상태를 나타냅니다. <details> 요소의 첫 번째 자식이 <summary> 요소라면, <summary>의 콘텐츠를 위젯의 레이블로 사용합니다.

 

https://developer.mozilla.org/ko/docs/Web/HTML/Element/details

 

<details> - HTML: Hypertext Markup Language | MDN

HTML <details> 요소는 "열림" 상태일 때만 내부 정보를 보여주는 정보 공개 위젯을 생성합니다. 요약이나 레이블은 <summary> 요소를 통해 제공할 수 있습니다.

developer.mozilla.org

Open 추가

$('details').attr('open','');

 

Opne 제거

$('details').removeAttr('open');

 

$('.info').on('click', 'details', function () {
    $('details').removeAttr('open');
    $(this).attr('open', '');
});

반응형

+ Recent posts